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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:  30
  TorBrowserTeam201911R  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by cypherpunks):

 Replying to [comment:95 gk]:
 > Replying to [comment:93 cypherpunks]:
 > > > I meant commit 65bbebea18a8 which is the patch for #14716.
 > > Oh, that one. Maybe, because `nsLoginManager.js` was removed in
 Firefox 68? :)
 >
 > More "moved": https://searchfox.org/mozilla-
 esr68/source/toolkit/components/passwordmgr/LoginManager.jsm has still
 almost all the code we patched for #14716. Yet, still...
 Smiley means it was a joke ;)
 Mozilla fixed https://bugzilla.mozilla.org/show_bug.cgi?id=1216882 during
 switching to SQL backend.
 Detailed description:
 https://bugzilla.mozilla.org/show_bug.cgi?id=783994#c19
 https://bugzilla.mozilla.org/show_bug.cgi?id=1389664 is where to start
 from.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:  30
  TorBrowserTeam201911R  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by gk):

 Replying to [comment:93 cypherpunks]:
 > > I meant commit 65bbebea18a8 which is the patch for #14716.
 > Oh, that one. Maybe, because `nsLoginManager.js` was removed in Firefox
 68? :)

 More "moved": https://searchfox.org/mozilla-
 esr68/source/toolkit/components/passwordmgr/LoginManager.jsm has still
 almost all the code we patched for #14716. Yet, still...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:  30
  TorBrowserTeam201911R  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by acat):

 * actualpoints:   => 30


Comment:

 > acat, et.al.: please add your points spent here (I know it's hard :) ).

 It is :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 > I meant commit 65bbebea18a8 which is the patch for #14716.
 Oh, that one. Maybe, because `nsLoginManager.js` was removed in Firefox
 68? :)
 The last related change was https://hg.mozilla.org/mozilla-
 central/rev/f52b086cbd9d
 If "no prompt after cancelling it 3 times" from STR of #14716 is a desired
 behavior, then we are good here.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 Replying to [comment:91 cypherpunks]:
 > Replying to [comment:90 gk]:
 > > {{{
 > > 3) Check whether/why 7d0bb93e5c4b can actually get dropped
 > > }}}
 > > is still open but I don't have time to investigate why this can get
 dropped now. If someone wants to dig a bit that would be highly
 appreciated, though.
 > Because it was a fix for your workaround for #24052, no? Now that
 Mozilla fixed that bug in esr68, and you removed any ability to run plug-
 ins, it is no longer needed.

 Yeah, that's right. I was actually mentioning the wrong commit, sorry. I
 meant commit 65bbebea18a8 which is the patch for #14716.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Replying to [comment:90 gk]:
 > {{{
 > 3) Check whether/why 7d0bb93e5c4b can actually get dropped
 > }}}
 > is still open but I don't have time to investigate why this can get
 dropped now. If someone wants to dig a bit that would be highly
 appreciated, though.
 Because it was a fix for your workaround for #24052, no? Now that Mozilla
 fixed that bug in esr68, and you removed any ability to run plug-ins, it
 is no longer needed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201911R  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

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


Comment:

 {{{
 3) Check whether/why 7d0bb93e5c4b can actually get dropped
 }}}
 is still open but I don't have time to investigate why this can get
 dropped now. If someone wants to dig a bit that would be highly
 appreciated, though.

 acat, et.al.: please add your points spent here (I know it's hard :) ).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:
  TorBrowserTeam201911R  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

 * keywords:
 ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201911,
 TorBrowserTeam201911R
 => ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201911R


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:85 pospeselr]:
 > dece7a15a8703596366c54f4420bd7286c66b10f looks good to me and from what
 I can tell through examination 988d41acfaca can most likely be entirely
 dropped (seeings how none of the code it touches exists anymore). I can do
 some testing on a build next week to make sure we don't have any edge
 cases, pretty sure I have a list of test cases from the original ticket in
 my notes somewhere.

 Thanks. Having some edge-case tests run would indeed be helpful.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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 pospeselr):

 dece7a15a8703596366c54f4420bd7286c66b10f looks good to me and from what I
 can tell through examination 988d41acfaca can most likely be entirely
 dropped (seeings how none of the code it touches exists anymore). I can do
 some testing on a build next week to make sure we don't have any edge
 cases, pretty sure I have a list of test cases from the original ticket in
 my notes somewhere.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:83 gk]:
 > We are close with this ticket. Things I still want to see/figure out are
 >
 > 1) Addressing comment:81

 That's done on `tor-browser-68.1.0esr-9.0-3` (commit
 ef66e9cb42a21dc55b5aee75450fb70e2cd1b77a).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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):

 We are close with this ticket. Things I still want to see/figure out are

 1) Addressing comment:81
 2) Check whether/why 988d41acfaca can actually get dropped
 3) Check whether/why 7d0bb93e5c4b can actually get dropped
 4) Second reviewer for code we have for #23247 now

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

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

[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:80 acat]:
 > Replying to [comment:77 gk]:
 > > Replying to [comment:75 gk]:
 > > > Replying to [comment:74 acat]:
 > > > > Fixed in https://github.com/acatarineu/tor-
 browser/commits/30429+11. I also changed the last check for the `.onion`
 case to `if ((mState & STATE_IS_SECURE) == 0) {`, because I think the
 previous `if (mState != STATE_IS_INSECURE) {` may have erased some flags
 in case of a https onion.
 > > > >
 > > > > I changed the comment, but not completely sure if you meant that
 or something else :)
 > > >
 > > > I meant something else but I was wrong. However, the changed comment
 *does* add value, so thanks. The patch looks good to me. I'd like to have
 another reviewer here (as this is a C++ patch), likely pospeselr.
 Menawhile, though, just a small nit to fix up:
 > > > {{{
 > > > +// router over tor (.onion).
 > > > }}}
 > > > s/router/routed/
 > >
 > > Additionally, it seems that somehow your patch is breaking the mobile
 experience. With the latest nightly I can see an onion icon and the
 session is marked as secure. However, testing your patch with my
 `30429_test` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=30429_test) just gives the regular globe and an
 insecure connection setting.
 >
 > I verified that the fixup in
 https://trac.torproject.org/projects/tor/ticket/31010#comment:35 fixes the
 mobile issue.
 >
 > Fixed the typo: https://www.github.com/acatarineu/tor-
 browser/commit/30429+12.

 Thanks. Looks good to me. I cherry-picked the fix to `tor-
 browser-68.1.0esr-9.0-2` (commit
 dece7a15a8703596366c54f4420bd7286c66b10f).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

[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
-+-
Changes (by acat):

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


Comment:

 Replying to [comment:77 gk]:
 > Replying to [comment:75 gk]:
 > > Replying to [comment:74 acat]:
 > > > Fixed in https://github.com/acatarineu/tor-browser/commits/30429+11.
 I also changed the last check for the `.onion` case to `if ((mState &
 STATE_IS_SECURE) == 0) {`, because I think the previous `if (mState !=
 STATE_IS_INSECURE) {` may have erased some flags in case of a https onion.
 > > >
 > > > I changed the comment, but not completely sure if you meant that or
 something else :)
 > >
 > > I meant something else but I was wrong. However, the changed comment
 *does* add value, so thanks. The patch looks good to me. I'd like to have
 another reviewer here (as this is a C++ patch), likely pospeselr.
 Menawhile, though, just a small nit to fix up:
 > > {{{
 > > +// router over tor (.onion).
 > > }}}
 > > s/router/routed/
 >
 > Additionally, it seems that somehow your patch is breaking the mobile
 experience. With the latest nightly I can see an onion icon and the
 session is marked as secure. However, testing your patch with my
 `30429_test` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=30429_test) just gives the regular globe and an
 insecure connection setting.

 I verified that the fixup in
 https://trac.torproject.org/projects/tor/ticket/31010#comment:35 fixes the
 mobile issue.

 Fixed the typo: https://www.github.com/acatarineu/tor-
 browser/commit/30429+12.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 Replying to [comment:75 gk]:
 > Replying to [comment:74 acat]:
 > > Fixed in https://github.com/acatarineu/tor-browser/commits/30429+11. I
 also changed the last check for the `.onion` case to `if ((mState &
 STATE_IS_SECURE) == 0) {`, because I think the previous `if (mState !=
 STATE_IS_INSECURE) {` may have erased some flags in case of a https onion.
 > >
 > > I changed the comment, but not completely sure if you meant that or
 something else :)
 >
 > I meant something else but I was wrong. However, the changed comment
 *does* add value, so thanks. The patch looks good to me. I'd like to have
 another reviewer here (as this is a C++ patch), likely pospeselr.
 Menawhile, though, just a small nit to fix up:
 > {{{
 > +// router over tor (.onion).
 > }}}
 > s/router/routed/

 Additionally, it seems that somehow your patch is breaking the mobile
 experience. With the latest nightly I can see an onion icon and the
 session is marked as secure. However, testing your patch with my
 `30429_test` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=30429_test) just gives the regular globe and an
 insecure connection setting.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 {{{
 +  mState = STATE_IS_SECURE;
 }}}
 to erase all other flags?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201909   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

 * keywords:  ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909R =>
 ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:74 acat]:
 > Fixed in https://github.com/acatarineu/tor-browser/commits/30429+11. I
 also changed the last check for the `.onion` case to `if ((mState &
 STATE_IS_SECURE) == 0) {`, because I think the previous `if (mState !=
 STATE_IS_INSECURE) {` may have erased some flags in case of a https onion.
 >
 > I changed the comment, but not completely sure if you meant that or
 something else :)

 I meant something else but I was wrong. However, the changed comment
 *does* add value, so thanks. The patch looks good to me. I'd like to have
 another reviewer here (as this is a C++ patch), likely pospeselr.
 Menawhile, though, just a small nit to fix up:
 {{{
 +// router over tor (.onion).
 }}}
 s/router/routed/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:
  TorBrowserTeam201909R  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by acat):

 * keywords:  ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909 =>
 ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909R
 * status:  needs_revision => needs_review


Comment:

 Fixed in https://github.com/acatarineu/tor-browser/commits/30429+11. I
 also changed the last check for the `.onion` case to `if ((mState &
 STATE_IS_SECURE) == 0) {`, because I think the previous `if (mState !=
 STATE_IS_INSECURE) {` may have erased some flags in case of a https onion.

 I changed the comment, but not completely sure if you meant that or
 something else :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201909   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

 * keywords:  ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909R =>
 ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909
 * status:  needs_review => needs_revision


Comment:

 So, it seems we have two new checks for "is this a .onion and should we
 treat this as trustworthy?". Could we use the one that actually is
 available in the tree instead
 (`nsMixedContentBlocker::IsPotentiallyTrustworthyOnion()`)? That would at
 least make in the `nsDocShell` sense given the mixed content context your
 changes are in. But in the others as well I feel. We should adapt
 `URICanBeConsideredSecure()`, too (which had the .onion check already. Not
 sure what *I* saw while reviewing previously ;) ).
 {{{
// If the security state is STATE_IS_INSECURE, the TLS handshake never
// completed. Don't set any further state.
 }}}
 Does not make much sense anymore with the code changes. Could you add a
 different comment explaining e.g. why we check for != INSECURE here after
 making sure there is actually a `securityInfo` available, which might not
 be obvious at first glance.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:
  TorBrowserTeam201909R  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by acat):

 * keywords:  ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909 =>
 ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909R
 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:64 gk]:
 > Replying to [comment:8 acat]:
 >
 > [snip]
 >
 > > == [DROP? might not be needed -> check]
 > > {{{
 > > + 988d41acfaca Bug 26456: HTTP .onion sites inherit previous page's
 certificate information
 > > }}}
 >
 > That's not clear yet, probably we don't need it. However, the current
 state of our rebased .onion security expectations needs improvements.
 Right now if you load an http:// .onion (you could pick one from
 https://onion.torproject.org) the proper icon is shown in the URL bar.
 But: clicking on the info box shows that the connection is not secure
 which is a regression to the stable series. `URICanBeConsideredSecure()`
 (in security/manager/ssl/nsSecureBrowserUIImpl.cpp) seems to be suspicious
 here as it does not care about .onion or not.

 Fixup in https://github.com/acatarineu/tor-browser/commit/30429+10. Not
 sure what I saw while rebasing, but clearly changing
 `URICanBeConsideredSecure` was necessary but not sufficient :)

 I also realized that the "mixed onion" icon was not being shown properly
 and marked as secure, so I also had to change
 `nsDocShell::GetAllowMixedContentAndConnectionData`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201909   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

 * keywords:  ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909R =>
 ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:68 mcs]:

 [snip]

 > All three patches are on the `bug30429-fixup-02` branch within the brade
 tor-browser repo.

 Looks good. I guess I'll adapt the commit message regarding the included
 fix for #18900 slightly when rebasing to take comment:67 into account but
 that's nothing we need to change right now. `tor-browser-68.1.0esr-9.0-2`
 has the three fixups (commit 87b3cdb0862a4912b0c3318ad63954dbf42bc774,
 d41c386fa1fc365e4962d96f5d99df063ba72dba, and
 74c3ea2d5152e3687cb9026c93cdd043e90beb76).

 Setting the state of this ticket back to `needs_revision` to address
 comment:64.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:
  TorBrowserTeam201909R  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by gk):

 Replying to [comment:67 mcs]:
 > Replying to [comment:66 gk]:
 > > Well, indeed I had forgotten about that. However, why does this issue
 apply to macOS which is the only platform that part of the patch is
 concerned about? I mean we set `LD_LIBRARY_PATH` on Linux with the start
 script, so I see why we ran into #18900 but we don't touch the respective
 env variable on macOS, no?
 >
 > On macOS we do have the `tor` script, although it does not currently
 modify `DYLD_LIBRARY_PATH` in a way that could cause a problem like
 #18900. However, the `strstr()` code is wrong and it seems risky to
 include it given the potential for future problems. Also, none of our
 recent Tor Browser releases have included the `strstr()` code so Kathy and
 I are not comfortable adding it this close to the 9.0 release.

 That's perfectly fine. I am interested to get the reasons for our omission
 right here, though, to make it easier for future readers (both us and
 anybody else) to understand why we did what.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:
  TorBrowserTeam201909R  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by mcs):

 * status:  needs_revision => needs_review
 * keywords:  ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909 =>
 ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909R


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

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

Comment (by mcs):

 Here is a patch that re-enables staged updates on macOS:
 https://gitweb.torproject.org/user/brade/tor-
 
browser.git/commit/?h=bug30429-fixup-02&id=87b3cdb0862a4912b0c3318ad63954dbf42bc774

 Here is a fix for the dev tools branding:
 https://gitweb.torproject.org/user/brade/tor-
 
browser.git/commit/?h=bug30429-fixup-02&id=d41c386fa1fc365e4962d96f5d99df063ba72dba

 Note that `devtools/client/themes/images/aboutdebugging-firefox-logo.svg`
 is a color image and it should be a black one that can be colorized via
 code. We filed #31803 to track that issue (but the color icon does not
 look terrible).

 Finally, here is a fix for the #13379 issues you mentioned in comment:62:
 https://gitweb.torproject.org/user/brade/tor-
 
browser.git/commit/?h=bug30429-fixup-02&id=74c3ea2d5152e3687cb9026c93cdd043e90beb76

 All three patches are on the `bug30429-fixup-02` branch within the brade
 tor-browser repo.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

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

Comment (by mcs):

 Replying to [comment:66 gk]:
 > Well, indeed I had forgotten about that. However, why does this issue
 apply to macOS which is the only platform that part of the patch is
 concerned about? I mean we set `LD_LIBRARY_PATH` on Linux with the start
 script, so I see why we ran into #18900 but we don't touch the respective
 env variable on macOS, no?

 On macOS we do have the `tor` script, although it does not currently
 modify `DYLD_LIBRARY_PATH` in a way that could cause a problem like
 #18900. However, the `strstr()` code is wrong and it seems risky to
 include it given the potential for future problems. Also, none of our
 recent Tor Browser releases have included the `strstr()` code so Kathy and
 I are not comfortable adding it this close to the 9.0 release.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 Replying to [comment:65 mcs]:
 > Replying to [comment:62 gk]:
 > > Any reason you omitted `!strstr(pathValue, pathToAppend)` in
 AppendToLibPath()? It might not be likely that this is an issue but having
 that check seems to be correct to me: there is no need to add the path if
 it's already there for whatever reason.
 >
 > You have forgotten about #18900 where we had to back out that part of
 Mozilla's code. With the ESR68 patches, we had to resurrect the entire
 `AppendToLibPath()` function (since Mozilla removed it completely) so we
 just omitted the problematic `strstr()` call in our implementation. We
 will add a mention of #18900 to the #13379 commit message.

 Well, indeed I had forgotten about that. However, why does this issue
 apply to macOS which is the only platform that part of the patch is
 concerned about? I mean we set `LD_LIBRARY_PATH` on Linux with the start
 script, so I see why we ran into #18900 but we don't touch the respective
 env variable on macOS, no?

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by mcs):

 Replying to [comment:62 gk]:
 > Here comes feedback for commit 21066b41d8844805876fa71e1ea562c5dfaac439:
 >
 > "This is used so that updater can find libmozsqlite3.so" s/updater/the
 updater/
 >
 > and not .so but .dylib in that comment as this is for macOS only.

 Thanks. We will produce a fixup for this. I think we will mention
 `libnss3.dylib` (as we do elsewhere in the patch).

 > "can located" -> can locate

 We will fix this too.

 > Any reason you omitted `!strstr(pathValue, pathToAppend)` in
 AppendToLibPath()? It might not be likely that this is an issue but having
 that check seems to be correct to me: there is no need to add the path if
 it's already there for whatever reason.

 You have forgotten about #18900 where we had to back out that part of
 Mozilla's code. With the ESR68 patches, we had to resurrect the entire
 `AppendToLibPath()` function (since Mozilla removed it completely) so we
 just omitted the problematic `strstr()` call in our implementation. We
 will add a mention of #18900 to the #13379 commit message.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 Replying to [comment:8 acat]:

 [snip]

 > == [DROP? might not be needed -> check]
 > {{{
 > + 988d41acfaca Bug 26456: HTTP .onion sites inherit previous page's
 certificate information
 > }}}

 That's not clear yet, probably we don't need it. However, the current
 state of our rebased .onion security expectations needs improvements.
 Right now if you load an http:// .onion (you could pick one from
 https://onion.torproject.org) the proper icon is shown in the URL bar.
 But: clicking on the info box shows that the connection is not secure
 which is a regression to the stable series. `URICanBeConsideredSecure()`
 (in security/manager/ssl/nsSecureBrowserUIImpl.cpp) seems to be suspicious
 here as it does not care about .onion or not.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 Replying to [comment:60 pili]:
 >
 > > We need an updated logo for `aboutdebugging-firefox-release.svg` at
 least, right? Do we have a bug for that on file? (one can see the issue
 after flipping `devtools.aboutdebugging.new-enabled` and then opening
 `about:debugging`)
 >
 > Do we have something we can use for this already or do we need antonela
 to make something?

 I think we can use the `firefox.svg` we have in the respective branding
 folders, like browser/branding/official. The issue just needs a fixup
 patch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 Here comes feedback for commit 21066b41d8844805876fa71e1ea562c5dfaac439:

 "This is used so that updater can find libmozsqlite3.so" s/updater/the
 updater/

 and not .so but .dylib in that comment as this is for macOS only.

 "can located" -> can locate

 Any reason you omitted `!strstr(pathValue, pathToAppend)` in
 AppendToLibPath()? It might not be likely that this is an issue but having
 that check seems to be correct to me: there is no need to add the path if
 it's already there for whatever reason.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

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

Comment (by mcs):

 Replying to [comment:59 gk]:
 > I took a look at commit 14df73ecfdd88db89f196cecfb934dab7e552969 (aka
 the rebased patch for #4234):
 >
 > Do we really want to disable staged updates for macOS? I feel if we
 don't have good reasons like we do for Windows and Linux we should a) not
 degrade the user experience here and b) not deviate from the update code
 path Mozilla is using (assuming that the alternative path is less tested).

 As we discussed on IRC, Kathy and I will create a fixup patch that keeps
 staged updates as the default on macOS.

 > We need an updated logo for `aboutdebugging-firefox-release.svg` at
 least, right? Do we have a bug for that on file? (one can see the issue
 after flipping `devtools.aboutdebugging.new-enabled` and then opening
 `about:debugging`)

 As far as I know there is no open ticket for this... but my fuzzy memory
 is that it was mentioned previously somewhere.

 > Why do we suddenly need the `#ifdef XP_WIN` blocks around
 `closeHandle()` and friends? Just to make it abundantly clear that this is
 only used for Windows as is the ctypes inclusion?

 Yes.

 > I wonder if we could that somehow upstream or make it clear upstream in
 a way that we don't have to carry that part of the patch around every
 time.

 We could just remove the added `#ifdef XP_WIN` lines. They are not
 essential. On the other hand, including them in our patch makes it more
 likely that we will notice any additions that Mozilla makes to their use
 of ctypes (which seems like a good thing, but does mean potentially more
 work during the routine rebasing that happens for point releases).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

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

Comment (by pili):

 > We need an updated logo for `aboutdebugging-firefox-release.svg` at
 least, right? Do we have a bug for that on file? (one can see the issue
 after flipping `devtools.aboutdebugging.new-enabled` and then opening
 `about:debugging`)

 Do we have something we can use for this already or do we need antonela to
 make 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] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 I took a look at commit 14df73ecfdd88db89f196cecfb934dab7e552969 (aka the
 rebased patch for #4234):

 Do we really want to disable staged updates for macOS? I feel if we don't
 have good reasons like we do for Windows and Linux we should a) not
 degrade the user experience here and b) not deviate from the update code
 path Mozilla is using (assuming that the alternative path is less tested).

 We need an updated logo for `aboutdebugging-firefox-release.svg` at least,
 right? Do we have a bug for that on file? (one can see the issue after
 flipping `devtools.aboutdebugging.new-enabled` and then opening
 `about:debugging`)

 Why do we suddenly need the `#ifdef XP_WIN` blocks around `closeHandle()`
 and friends? Just to make it abundantly clear that this is only used for
 Windows as is the ctypes inclusion? I wonder if we could that somehow
 upstream or make it clear upstream in a way  that we don't have to carry
 that part of the patch around every time.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 FWIW I just filed #31059 as we seem to have missed at least the
 letterboxing pref in the rebase.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 Replying to [comment:56 acat]:

 [snip]

 > A fixup for the Part 7 is in https://github.com/acatarineu/tor-
 browser/commit/30429+9

 Thanks. Looks good. I cherry-picked the fixup onto `tor-
 browser-68.1.0esr-9.0-2` (commit
 a8c2fe1a361abb926e6dbbce91940a1c56b0b9bf).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

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

Comment (by acat):

 Replying to [comment:47 gk]:
 > Replying to [comment:44 acat]:
 > > New branch: https://github.com/acatarineu/tor-browser/commits/30429+8
 > >
 > > It has latest missing desktop patches from tor-
 browser-60.8.0esr-9.0-1, the latest updater patches, backported #27601
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1330467) and #28711
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1474659) and I also added
 the missing changes to the patch for #25702, which was to copy the release
 `pref/firefox-branding.js` over the nightly and alpha ones, now that the
 updater patches are there.
 >
 > I'll comment separately on the onboarding patches in #28822. Here come
 the relevant comment for commits besides them:
 >
 > 0c19ff1358931bfa1be03dca261ec4d84a9826ee -- okay
 >
 > The backported patches for bug 1330467 look mostly good. Part 7 as tiny
 mistake. You end up with:
 > {{{
 > -  // make sure principals with userContextId or firstPartyDomain use
 the same permissions
 > +  // make sure principals with a firstPartyDomain use different
 permissions
 >Assert.equal(
 >  Ci.nsIPermissionManager.ALLOW_ACTION,
 >  pm.testPermissionFromPrincipal(principal6, TEST_PERMISSION)
 >);
 >Assert.equal(
 > -Ci.nsIPermissionManager.ALLOW_ACTION,
 > +Ci.nsIPermissionManager.UNKNOWN_ACTION,
 >  pm.testPermissionFromPrincipal(principal7, TEST_PERMISSION)
 >);
 > }}}
 > but the original is
 > {{{
 > -  // make sure principals with userContextId or firstPartyDomain use
 the same permissions
 > +  // make sure principals with userContextId use the same permissions
 >Assert.equal(Ci.nsIPermissionManager.ALLOW_ACTION,
 > pm.testPermissionFromPrincipal(principal6,
 TEST_PERMISSION));
 > -  Assert.equal(Ci.nsIPermissionManager.ALLOW_ACTION,
 > +  // make sure principals with a firstPartyDomain use different
 permissions
 > +  Assert.equal(Ci.nsIPermissionManager.UNKNOWN_ACTION,
 > pm.testPermissionFromPrincipal(principal7,
 TEST_PERMISSION));
 > }}}
 >
 > cbe8a7e484d4217be86edb0e5cf81709bfe9df68 - okay (mabye squash with
 #25658?)
 > 1d4f025ccbefad61498044a1e7e1040e935fc736 - okay (mabye squash with
 #25658?)
 > fb50127d4f55e8ec102be1a3f7316f96ae2fb578 - okay
 > a96dc99a94a687cf4ed6f39ecb4bd09f60e63734 - okay
 > 849d7121914c595e78e35f068b099c46ba1c6e9a - okay
 >
 > I am still debating taking the permission API patches out of the final
 alpha branch. But for now (one or two nightlies) I let them in. So, fixing
 up the tiny mistake above should be a fixup then as I am about to push a
 68.1.0esr branch for further testing.

 A fixup for the Part 7 is in https://github.com/acatarineu/tor-
 browser/commit/30429+9

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201909   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by pili):

 * points:   => 1


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

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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by mcs):

 Replying to [comment:51 cypherpunks]:
 > No. We want either of these things. Because it's "the right thing" (part
 of sandboxing). But `CommonAppData` should point to e.g. `C:\Tor
 Browser\Browser\TorBrowser\Data\Browser\Mozilla` instead of
 `C:\ProgramData\Mozilla`.

 Maybe, but we do not have time to patch or test such a scheme right now. I
 think we are better off without the complexity that this adds for
 developers and users of Tor Browser.

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

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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by cypherpunks):

 > Mozilla moved the app.update.auto setting to a new JSON file that is
 designed to be shared across all Firefox profiles. Firefox also stores
 some update-related data (on Windows only) in a system location and we do
 not want either of these things.
 No. We want either of these things. Because it's "the right thing" (part
 of sandboxing). But `CommonAppData` should point to e.g. `C:\Tor
 Browser\Browser\TorBrowser\Data\Browser\Mozilla` instead of
 `C:\ProgramData\Mozilla`.
 > Please let me know if we need to create a new ticket for these
 Yes, please.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by gk):

 Replying to [comment:49 mcs]:
 > Here is a fixup for the #4234 patch which contains fixes for some
 Windows updater issues that Kathy and I found:
 >
 > https://gitweb.torproject.org/user/brade/tor-
 
browser.git/commit/?h=bug30429-fixup-01&id=f607d5bb45e536dc7094999252dc89c6bc84884b
 >
 > Mozilla moved the app.update.auto setting to a new JSON file that is
 designed to be shared across all Firefox profiles. Firefox also stores
 some update-related data (on Windows only) in a system location and we do
 not want either of these things.
 >
 > Please let me know if we need to create a new ticket for these; for now
 I am using this ticket because it is still open.

 Here is fine, thanks. The patch looks good to me. Merged to`tor-
 browser-68.1.0esr-9.0-1` (commit
 f607d5bb45e536dc7094999252dc89c6bc84884b).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by mcs):

 Here is a fixup for the #4234 patch which contains fixes for some Windows
 updater issues that Kathy and I found:

 https://gitweb.torproject.org/user/brade/tor-
 
browser.git/commit/?h=bug30429-fixup-01&id=f607d5bb45e536dc7094999252dc89c6bc84884b

 Mozilla moved the app.update.auto setting to a new JSON file that is
 designed to be shared across all Firefox profiles. Firefox also stores
 some update-related data (on Windows only) in a system location and we do
 not want either of these things.

 Please let me know if we need to create a new ticket for these; for now I
 am using this ticket because it is still open.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by gk):

 Alright, I just pushed `tor-browser-68.1.0esr-9.0-1` to our `tor-browser`
 repo. Please use that one for basing your branches and fixup commits on.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

 * keywords:  ff68-esr, tbb-9.0-must-nightly, TorBrowserTeam201908R =>
 ff68-esr, tbb-9.0-must-nightly, TorBrowserTeam201908
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:44 acat]:
 > New branch: https://github.com/acatarineu/tor-browser/commits/30429+8
 >
 > It has latest missing desktop patches from tor-browser-60.8.0esr-9.0-1,
 the latest updater patches, backported #27601
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1330467) and #28711
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1474659) and I also added
 the missing changes to the patch for #25702, which was to copy the release
 `pref/firefox-branding.js` over the nightly and alpha ones, now that the
 updater patches are there.

 I'll comment separately on the onboarding patches in #28822. Here come the
 relevant comment for commits besides them:

 0c19ff1358931bfa1be03dca261ec4d84a9826ee -- okay

 The backported patches for bug 1330467 look mostly good. Part 7 as tiny
 mistake. You end up with:
 {{{
 -  // make sure principals with userContextId or firstPartyDomain use the
 same permissions
 +  // make sure principals with a firstPartyDomain use different
 permissions
Assert.equal(
  Ci.nsIPermissionManager.ALLOW_ACTION,
  pm.testPermissionFromPrincipal(principal6, TEST_PERMISSION)
);
Assert.equal(
 -Ci.nsIPermissionManager.ALLOW_ACTION,
 +Ci.nsIPermissionManager.UNKNOWN_ACTION,
  pm.testPermissionFromPrincipal(principal7, TEST_PERMISSION)
);
 }}}
 but the original is
 {{{
 -  // make sure principals with userContextId or firstPartyDomain use the
 same permissions
 +  // make sure principals with userContextId use the same permissions
Assert.equal(Ci.nsIPermissionManager.ALLOW_ACTION,
 pm.testPermissionFromPrincipal(principal6,
 TEST_PERMISSION));
 -  Assert.equal(Ci.nsIPermissionManager.ALLOW_ACTION,
 +  // make sure principals with a firstPartyDomain use different
 permissions
 +  Assert.equal(Ci.nsIPermissionManager.UNKNOWN_ACTION,
 pm.testPermissionFromPrincipal(principal7,
 TEST_PERMISSION));
 }}}

 cbe8a7e484d4217be86edb0e5cf81709bfe9df68 - okay (mabye squash with
 #25658?)
 1d4f025ccbefad61498044a1e7e1040e935fc736 - okay (mabye squash with
 #25658?)
 fb50127d4f55e8ec102be1a3f7316f96ae2fb578 - okay
 a96dc99a94a687cf4ed6f39ecb4bd09f60e63734 - okay
 849d7121914c595e78e35f068b099c46ba1c6e9a - okay

 I am still debating taking the permission API patches out of the final
 alpha branch. But for now (one or two nightlies) I let them in. So, fixing
 up the tiny mistake above should be a fixup then as I am about to push a
 68.1.0esr branch for further testing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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-nightly,  |  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by gk):

 Replying to [comment:42 acat]:
 > These look good to me.

 Alright, I pushed `tor-browser-68.0esr-9.0-3` and enabled .mar file
 generation on `tor-browser-build`'s `master` again
 (536715a6c5d134bc25ebb07147c81c422c11c3b3) after pointing to the new
 browser branch (commit c54f90e102124dcd77d6efb9e186a4e3215972a8). We'll
 see how it goes in tomorrow's nightly build.

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

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

[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-nightly,  |  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by acat):

 * 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] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by acat):

 New branch: https://github.com/acatarineu/tor-browser/commits/30429+8

 It has latest missing desktop patches from tor-browser-60.8.0esr-9.0-1,
 the latest updater patches, backported #27601
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1330467) and #28711
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1474659) and I also added
 the missing changes to the patch for #25702, which was to copy the release
 `pref/firefox-branding.js` over the nightly and alpha ones, now that the
 updater patches are there.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 These look good 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] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:40 mcs]:
 > We will revise the patches.

 The revised commits are on the `bug30429-pc-04` branch within brade's tor-
 browser repo (https://gitweb.torproject.org/user/brade/tor-
 browser.git/log/?h=bug30429-pc-04). Here are the commit hashes:
 {{{
 441c06803de45ef4361b73d8a89dc157ac36b931 // #13252
 ce12bc2c589e3afee005d21390a5a8fdc5dba839 // #19121 part 1
 1ce0013447ad026bd9a63423e6a4c8fa3a8e55a1 // #19121 part 2
 2333721bb8db38a04edc40ed9896723f57c283b6 // #4234
 0e5f7c647affc5951d125193f05ba1330b4e8167 // #13379
 }}}
 And the two fixups:
 {{{
 68f67b9d87c9b7a0952b4b777532748370c0442d // fixup for #16940
 2e6c050c1c44bd36ec7c8747dd66ef8d4cf146b3 // fixup for "TB4: Tor Browser's
 Firefox preference overrides."
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:33 acat]:
 > Some comments on the updater patches:
 >
 > 9f9017a63b156e11af23b55fde36223b74d859e4 (Bug 13379: Sign our MAR
 files.) -
 > - In the original esr60 patch, `AppendToLibPath` is called for Windows,
 Mac and Linux, while in the new patch it's only used for  Mac. Is this not
 needed anymore for Linux and Windows? In #29818 it says that in Linux now
 `-rpath=$ORIGIN` is used, but I did not see anything about Windows.

 We do not think it will be needed on Windows because Mozilla no longer
 copies `updater.exe` to a new location and the DLLs it depends on are in
 the same directory as that exe. But we will find out for sure when we are
 able to test the ESR68-based updater on Windows (we are waiting for
 Windows nightlies to be available before we do that testing).

 > 9aa2a90005dde6a7ea2bf58b63241d27912a78eb (Bug 4234: Use the Firefox
 Update Process for Tor Browser.)
 >   - `TOR_BROWSER_VERSION` is now mandatory, if I understand it
 correctly. But I still see some cases that are checking whether
 `TOR_BROWSER_VERSION_QUOTED` is defined:
 > ...

 We will remove the #ifdefs.

 > {{{
 > +#ifdef TOR_BROWSER_VERSION_QUOTED
 > +  nsAutoCString tbVersion(TOR_BROWSER_VERSION_QUOTED);
 > +  rv = parser.GetString("Compatibility", "LastTorBrowserVersion", buf);
 > +  if (NS_FAILED(rv) || !tbVersion.Equals(buf)) return false;
 > +#endif
 > }}}
 >
 > {{{
 > +#ifdef TOR_BROWSER_VERSION_QUOTED
 > +  nsAutoCString tbVersion(TOR_BROWSER_VERSION_QUOTED);
 > +  static const char kTorBrowserVersionHeader[] =
 > +  NS_LINEBREAK "LastTorBrowserVersion=";
 > +  PR_Write(fd, kTorBrowserVersionHeader,
 sizeof(kTorBrowserVersionHeader) - 1);
 > +  PR_Write(fd, tbVersion.get(), tbVersion.Length());
 > +#endif
 > +
 > }}}
 >   Can these checks be removed?
 >
 >   - `AdjustPathForUpdater` in `toolkit/xre/nsUpdateDriver.cpp` is
 removed, similar to comment above, is this not needed anymore for Windows?

 It should not be needed. Also see what I said about
 `AdjustPathForUpdater()` in comment:31.

 > ...
 > 89177dd51ae361d5360abae00387a1d75c15a1be (fixup! TB4: Tor Browser's
 Firefox preference overrides.)
 > - Since `TOR_BROWSER_VERSION` is now mandatory, can the ifdef check
 be removed?
 >
 > 55b4bcecc587bb03ce32933096b12fbfb5ceb146 (fixup! Bug 16940: After
 update, load local change notes.)
 >   - Since `TOR_BROWSER_VERSION` is now mandatory, can the ifdef
 check be removed?

 Yes and yes.

 We will revise the patches.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:37 acat]:
 > Ok, I ended up removing it and changing the commit message here:
 https://github.com/acatarineu/tor-browser/commits/30429+7

 Looks good to me. Could you go over the latest commits that landed on
 `tor-browser-60.8.0esr-9.0-1` while we did our back and forth with the
 rebase review and pick those necessary for esr68 up? (To make sure we
 don't have anything that meanwhile landed forgotten)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-9.0-must-nightly, TorBrowserTeam201908R => ff68-esr,
 tbb-9.0-must-nightly, TorBrowserTeam201908R


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 Ok, I ended up removing it and changing the commit message here:
 https://github.com/acatarineu/tor-browser/commits/30429+7

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:35 acat]:
 > >Could you adapt the commit message for
 3fe947023d1146e61dfe08f941cc269e2441cd62? You could just drop the ESR45
 paragraph or change it in a way that reflects what we actually block with
 the patch.
 > One question regarding that commit, will the `meek-http-
 hel...@bamsoftware.com` exemption still be needed? I think that is a
 bootstrapped extension, which will not work in ESR68, and from what I see
 in #29430 the plan is to replace it with something else. Should we also
 remove this exemption here?

 Up to you. :) I am fine seeing the necessary bits in a fixup commit done
 in #29430 or just taking action right now in this bug while rebasing
 everything.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 >Could you adapt the commit message for
 3fe947023d1146e61dfe08f941cc269e2441cd62? You could just drop the ESR45
 paragraph or change it in a way that reflects what we actually block with
 the patch.
 One question regarding that commit, will the `meek-http-
 hel...@bamsoftware.com` exemption still be needed? I think that is a
 bootstrapped extension, which will not work in ESR68, and from what I see
 in #29430 the plan is to replace it with something else. Should we also
 remove this exemption here?

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

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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:30 acat]:
 > The patch looks good to me, also tested in Linux.

 Looks good to me, too. It's commit
 752fcc36bde612c146adae002b8ef9e1e1a119ac `tor-browser-68.0esr-9.0-2` and
 should be available with 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

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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 Some comments on the updater patches:

 9f9017a63b156e11af23b55fde36223b74d859e4 (Bug 13379: Sign our MAR files.)
 -
 - In the original esr60 patch, `AppendToLibPath` is called for Windows,
 Mac and Linux, while in the new patch it's only used for  Mac. Is this not
 needed anymore for Linux and Windows? In #29818 it says that in Linux now
 `-rpath=$ORIGIN` is used, but I did not see anything about Windows.

 9aa2a90005dde6a7ea2bf58b63241d27912a78eb (Bug 4234: Use the Firefox Update
 Process for Tor Browser.)
 - `TOR_BROWSER_VERSION` is now mandatory, if I understand it
 correctly. But I still see some cases that are checking whether
 `TOR_BROWSER_VERSION_QUOTED` is defined:

 {{{
 +#ifdef TOR_BROWSER_VERSION_QUOTED
 +  nsAutoCString tbVersion(TOR_BROWSER_VERSION_QUOTED);
 +  rv = parser.GetString("Compatibility", "LastTorBrowserVersion", buf);
 +  if (NS_FAILED(rv) || !tbVersion.Equals(buf)) return false;
 +#endif
 }}}

 {{{
 +#ifdef TOR_BROWSER_VERSION_QUOTED
 +  nsAutoCString tbVersion(TOR_BROWSER_VERSION_QUOTED);
 +  static const char kTorBrowserVersionHeader[] =
 +  NS_LINEBREAK "LastTorBrowserVersion=";
 +  PR_Write(fd, kTorBrowserVersionHeader, sizeof(kTorBrowserVersionHeader)
 - 1);
 +  PR_Write(fd, tbVersion.get(), tbVersion.Length());
 +#endif
 +
 }}}
 Can these checks be removed?

 - `AdjustPathForUpdater` in `toolkit/xre/nsUpdateDriver.cpp` is
 removed, similar to comment above, is this not needed anymore for Windows?

 afb98b58e51c64f4a5a8f51ff68cbd4a801dc831 (Bug 19121: reinstate the
 update.xml hash check) - ok

 bff9eb4e1fc5244b53533f4fdbbc43a0ffbd43fd (Bug 19121: reinstate the
 update.xml hash check) - ok

 88bc9543973ac089fcb9a3c5c9aae2295086e99b (Bug 13252: Do not store data in
 the app bundle) - ok, already reviewed

 89177dd51ae361d5360abae00387a1d75c15a1be (fixup! TB4: Tor Browser's
 Firefox preference overrides.)
 - Since `TOR_BROWSER_VERSION` is now mandatory, can the ifdef check be
 removed?

 55b4bcecc587bb03ce32933096b12fbfb5ceb146 (fixup! Bug 16940: After update,
 load local change notes.)
 - Since `TOR_BROWSER_VERSION` is now mandatory, can the ifdef
 check be removed?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:26 acat]:
 > Thanks again for the reviews. A new branch addressing your comments and
 some small issues I found: https://github.com/acatarineu/tor-
 browser/commits/30429+6

 Looks mostly good now (I still need to look at the onboarding stuff,
 though):

 [snip]

 > >9442dda80f9beb90b90934da2bb1a614d39117a4 - not okay. The test is
 probably not working anymore as we don't have static pins for #29811; we
 should either drop it or fix #29811 and test that the test is still
 working then (or working then again)
 > I dropped it, i can add a comment to #29811 to add it again when it is
 fixed.

 Sounds good, please do.

 [snip]

 Could you adapt the commit message for
 3fe947023d1146e61dfe08f941cc269e2441cd62? You could just drop the ESR45
 paragraph or change it in a way that reflects what we actually block with
 the patch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 The updater patches are ready for review now. Please examine the following
 commits on our bug30429-pc-03 branch within the brade tor-browser.git repo
 (https://gitweb.torproject.org/user/brade/tor-
 browser.git/log/?h=bug30429-pc-03):
 {{{
 9f9017a63b156e11af23b55fde36223b74d859e4
 Bug 13379: Sign our MAR files.

 9aa2a90005dde6a7ea2bf58b63241d27912a78eb
 Bug 4234: Use the Firefox Update Process for Tor Browser.

 afb98b58e51c64f4a5a8f51ff68cbd4a801dc831
 Bug 19121: reinstate the update.xml hash check

 bff9eb4e1fc5244b53533f4fdbbc43a0ffbd43fd
 Bug 19121: reinstate the update.xml hash check

 88bc9543973ac089fcb9a3c5c9aae2295086e99b
 Bug 13252: Do not store data in the app bundle
 }}}
 Also, that branch includes a couple of fixup commits that will be needed:
 {{{
 89177dd51ae361d5360abae00387a1d75c15a1be
 fixup! TB4: Tor Browser's Firefox preference overrides.

 55b4bcecc587bb03ce32933096b12fbfb5ceb146
 fixup! Bug 16940: After update, load local change notes.
 }}}

 We inserted them into the patch sequence in a logical place (similar to
 where they are in the ESR60-based Tor Browser).

 We did some testing of all of these patches together on macOS and Linux,
 but not on Windows.

 If you compare the ESR60 and ESR68 patches for #4234, you will notice that
 we omitted the `AdjustPathForUpdater()` code inside
 toolkit/xre/nsUpdateDriver.cpp. The #13379 contains the changes that are
 needed (look for `AppendToLibPath()`) and in ESR60 that #13379 patch just
 removes the `AdjustPathForUpdater()` code that is added by the #4234 patch
 (which seems silly since we don't plan to ever use the #4234 patch without
 the #13379 one).

 We confirmed that the #29180 patch is no longer needed.

 Finally, we noticed a few miscellaneous issues while testing in ESR68 and
 we will open new tickets for them. For example, our Linux alpha build
 wants to create a new profile directory named `RANDOM.default-alpha` which
 is not good for Tor Browser.

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

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

[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:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 The patch looks good to me, also tested in Linux.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Here is a rebased patch for #13252:
 https://gitweb.torproject.org/user/brade/tor-
 
browser.git/commit/?h=bug30429-pc-02&id=ba40aaeb975ed6680c79dca8f30b8285ec3578d4

 Even though Kathy and I are not finished with the updater patches yet, it
 would be good to include this patch in the nightly builds soon. It should
 be inserted into the sequence of patches after the #11641 patch (commit
 7521e628b071c61b65bcb9fa5e99c820369183c8 on acat's 30429+6 branch). Some
 notes about the rebased patch:

 1. We removed the code that copied files from distribution/preferences to
 the user's profile (XPIProvider.jsm). This was not needed even for ESR60.

 2. We removed the old Mac profile migration code. This is no longer needed
 because (a) everyone should have have upgraded (and therefore migrated)
 years ago and (b) Tor Browser 8.0 was a watershed release, so someone who
 does update a pre-8.0 Tor Browser to 9.x will have their profile migrated
 by the 8.0 code.

 acat and/or gk, please 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] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

[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:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by acat):

 * status:  needs_revision => needs_review
 * keywords:  tbb-9.0-must-nightly, TorBrowserTeam201908 => tbb-9.0-must-
 nightly, TorBrowserTeam201908R


Comment:

 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] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Nice work, acat. If you want another review, set `needs_review`. To get it
 form the tbb-team, set `TorBrowserTeam201908R`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 Thanks again for the reviews. A new branch addressing your comments and
 some small issues I found: https://github.com/acatarineu/tor-
 browser/commits/30429+6

 ---

 > d61046e445419d7c990571aace0616d1663d4a4d - not okay. It's confusing to
 put the Torbutton related part in this commit. Let's have it in the
 respective integration commit instead (the one for #10760 for example).
 Thanks, this must have slipped in one of the conflicts while rebasing.
 Note I also fixed a bug in each commit I noticed:
 `loc.installer.uninstallAddon` instead of `loc.uninstallAddon`.

 ---

 >>>What is the reason to patch GetUser$Directory now while we did not have
 done so in the esr60 patch? (I guess we should follow Mozilla here and if
 not, please add some comment/explanation for that deviation)
 >>Not sure if you mean changing the static calls by the non-static ones.
 If so, this is needed because the patch needs to make several
 GetUser$Directory non-static, and apparently in esr60 the static functions
 were called via object (I would expect C++ to at least warn if you call a
 static method via an object?).
 >Yes, that's what I mean. We should comment the reason for that change at
 least, like explaining why they suddenly need to be non-static, in
 particular given that Mozilla does not make that change but we have to
 now.
 >...
 >d03d360bd773c8d8a97ef1f69e565afcc19796e5 - not okay (comment is still
 missing)
 Ok, added a comment in the declaration of the function which causes all
 the static->non-static changes. Please let me know if you were thinking of
 something else.

 ---

 >9442dda80f9beb90b90934da2bb1a614d39117a4 - not okay. The test is probably
 not working anymore as we don't have static pins for #29811; we should
 either drop it or fix #29811 and test that the test is still working then
 (or working then again)
 I dropped it, i can add a comment to #29811 to add it again when it is
 fixed.

 ---

 >062794f7cb6819ec1a8a34f3117f8f6b03eaacf8 - not okay (note :ja-JP-mac ->
 ja; so mabye we need to adapt tor-browser-build here?)
 >We just need changes to the locales we support, e.g. not be but es-AR.
 You find the full list e.g. in tor-browser-build's rbm.conf.
 Sorry, I looked at the wrong source I guess, should be fixed.

 ---

 >>This is working fine the first time I open the browser, but
 unfortunately for some reason after restarting it the search engine icons
 disappear (although they still work). I'll try to find out why, but I
 think this should not be a blocker for a nightly. It might also be
 possible that it's some issue with my local build, so we can see if it
 reproduces.
 >How did that go? Any further insight here?
 I still did not find the cause, but I tested reverting this patch and the
 issue still happens to me with the Firefox default search engines, so it's
 either an issue with my local build that only happens to me, or caused by
 some other patch. But I think we can see in the nightly.

 ---

 >While "reusing" the existing search engines, did you make sure they
 comply with what we shipped so far. For example the ddg.xml we ship in our
 esr60 branches makes sure the requests go out via POST and there is no
 further information transmitted to DDG, while the one we reuse in esr68
 seems at least to have differentiation about how things got searched
 (context menu, searchbar etc.). I think we don't want to have those.
 Ok, I changed the default ddg to use POST as before, removed the params,
 and also changed the icon for the current one, so that it can be
 distinguised from the .onion one (I guess that's the reason why they are
 different). Also removed these params from the yahoo search, even though I
 think they were already in esr60 yahoo.xml. Also changed some search
 extensions so that they are not localized, took the strings from the
 english version and replaced them in the manifests. Then I removed the
 _locales folder for these search extensions, since they were not used
 anymore. Removing these is probably not strictly needed, but I did just in
 case, to mak

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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:24 gk]:
 > > True, did it. But I realized that now `onPageHide` does nothing, which
 seems wrong. Can we also remove it? I'm not sure if the new patch changes
 some behaviour here, since I guess before onpagehide would stop updating
 the document?
 >
 > That's probably a question for mcs and brade and/or trying things out. I
 don't know the answer with a bunch of further investigations.

 Kathy and I think that onPageHide() can be removed since its purpose was
 to remove the listeners that presumably are now removed for us via the
 `LEGACY_ACTORS` mechanism. We only need a "one time" update at page load
 time. But it would be good to test things by loading about:tbupdate and
 making sure the version and release date are filled in.

 > 2a324a0e0db60fc42d714d73657833d3cdf438cc - okay (mcs/brade second look;
 are we good with the "second call earlier"-part?)

 This looks good to us. We tested the "access denied" case on macOS and saw
 an error alert as expected. We also tried to test the "read only file"
 system case but we did not seen an alert. I made a note to test that
 scenario again when Kathy and I are in a better position to debug it (we
 are in the middle of rebasing updater patches at the moment). I think we
 should use this patch for now and fix it up later if necessary,

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  tbb-9.0-must-nightly, TorBrowserTeam201908R => tbb-9.0-must-
 nightly, TorBrowserTeam201908


Comment:

 Replying to [comment:17 acat]:

 [snip]

 > I also realized that in `Bug 8312: Remove "This plugin is disabled"
 barrier.` there is a `doc.getAnonymousElementByAttribute` but I do not see
 any defined `doc` variable. It's the same in 52, but I think in the
 previous version there was. So I added the `doc` definition, although I
 would have to test this to make sure if it works as intended.

 Nice catch (and sounds reasonable to me)! Don't spend too much time
 testing the Flash use case, though. :)

 > A question before comments: would it also make sense to try to upstream
 Bug #5741, with a different commit name and behind the --proxy-bypass-
 protection flag?

 I think it would make sense to make sure configurations with a SOCKS proxy
 set and remote resolution of DNS to not be able to bypass that if the flag
 is set. So, I am all for it to get that upstreamed.

 > Some comments:
 > >please add --enable-proxy-bypass-protection to all mozconfigs
 > Do you mean `.mozconfig-mac`, `.mozconfig-asan`, `.mozconfig` and
 `.mozconfig-mingw`? If so, isn't it already there?

 Hrm. I *think* I might have mixed this up with the state of `tor-browser-
 build`, sorry.

 > > 23b8e34d8fa64affdb265911ff586d8babf1a119 - should we not point to the
 latest Torbutton commit (especially as we have removed all the other
 Torbutton commit updates (rightly so))? otherwise okay
 > I think so, but I kept the submodule change in a separate commit since
 it's currently it's in my personal branch. Would it be ok to make the last
 `WIP torbutton submodule change` commit a fixup when we have an "official"
 torbutton "esr68" branch?

 Yes, that's cool.

 > >  a8c48df07cc505bd45c764d223f6ff01de738f31 -- indentation (keep
 original):
 > >
 > >+  nsresult rv = GetOverrideStringBundleForLocale(
 > >+  aSBS, uriString.get(), userAgentLocale.get(), aResult);
 > `mach clang-format` is changing this one, should we keep the original
 indentation anyway?

 Let's go with what Mozilla's tool wants to have here (and in other cases).

 > >There is no docshell/test/mochitest.ini in esr68 and we should not add
 one.
 > Thanks. I also realized I removed I accidentally removed a test
 `[test_bug1507702.html]`, fixed that too.
 >
 > >Why GetComputedReferrer() and not GetOriginalReferrer()? Could you add
 an explaining comment here?
 > I think `GetComputedReferrer()` is the one that preserves the current
 patch behaviour (e.g. takes into consideration referrer policy). Actually,
 when you mentioned I was not sure whether this was something intended. For
 example, with a noreferrer policy navigating through pages of the same
 origin will always clear `window.name`. But I saw #3414, so this actually
 seems to be the intended behaviour. I added a comment in the code.

 Thanks, sounds good.

 > >You are not including components.conf in libmdns moz.build instead of
 patching it as you did in the provider case; we should have the same
 approach inboth cases (I am fine with just the moz.build one if we think
 that's enough)
 > Ok, I reincluded `components.conf` in `moz.build`, and made the
 corresponding components.conf empty. Not sure if you meant this, or that
 we actually don't need to touch `libmdns` `components.conf`.

 What I meant was to approach the patching in both cases the same way: if
 we patch in dom/presentation both `moz.build` and the conf file then it
 makes it easier to understand the whole patch set if we do that in the
 libmdns case, too. So, I think the result is fine.

 > > What is the reason to patch GetUser$Directory now while we did not
 have done so in the esr60 patch? (I guess we should follow Mozilla here
 and if not, please add some comment/explanation for that deviation)
 > Not sure if you mean changing the static calls by the non-static ones.
 If so, this is needed because the patch needs to make several
 `GetUser$Directory` non-static, and appa

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

[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:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:22 acat]:
 > I realized that the changes for the security slider translations
 deduplication got accidentally lost when moving from 30429+2 to 30429+3.
 But maybe we should actually keep it this way and do the full change in
 #24653 (in tor-browser and torbutton).

 Yes, that's a good idea.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 I realized that the changes for the security slider translations
 deduplication got accidentally lost when moving from 30429+2 to 30429+3.
 But maybe we should actually keep it this way and do the full change in
 #24653 (in tor-browser and torbutton).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:  TorBrowserTeam201907R, tbb-9.0   |  Actual Points:
  -must-nightly  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:19 acat]:
 > Not so important, but I was wondering whether it would be ok to do a
 last pass to fix style issues whenever we think we have a branch ready for
 nightly. I can do this, and it cannot take more than 1 day.
 >
 > I think almost all C++ style should be fine according to `./mach clang-
 format`, but I was thinking to also make the JavaScript code we add or
 modify obey mozilla style (ESLint rules). Many of the style issues can be
 fixed automatically. The rules are quite advanced and tuned to Firefox
 codebase, and sometimes they help fixing bugs (deprecated things in XPCOM,
 etc.). I saw this while working on torbutton integration.

 Good idea, let's do it. I am fine not blocking on our nightly releases for
 this but commit a fixup commit which then gets resolved during a later
 rebase (just if we don't get to it in time).

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

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

[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:  TorBrowserTeam201907R, tbb-9.0   |  Actual Points:
  -must-nightly  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 Not so important, but I was wondering whether it would be ok to do a last
 pass to fix style issues whenever we think we have a branch ready for
 nightly. I can do this, and it cannot take more than 1 day.

 I think almost all C++ style should be fine according to `./mach clang-
 format`, but I was thinking to also make the JavaScript code we add or
 modify obey mozilla style (ESLint rules). Many of the style issues can be
 fixed automatically. The rules are quite advanced and tuned to Firefox
 codebase, and sometimes they help fixing bugs (deprecated things in XPCOM,
 etc.). I saw this while working on torbutton integration.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:  TorBrowserTeam201907R, tbb-9.0   |  Actual Points:
  -must-nightly  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by acat):

 * keywords:  TorBrowserTeam201907, tbb-9.0-must-nightly =>
 TorBrowserTeam201907R, tbb-9.0-must-nightly
 * 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] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201907, tbb-9.0-must-  |  Actual Points:
  nightly|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 Thanks for the reviews, GeKo, mcs/brade.

 I took branch https://github.com/acatarineu/tor-browser/commits/30429+2
 (which is the one resulting of #10760 changes) and addressed the review
 comments there, resulting on https://github.com/acatarineu/tor-
 browser/commits/30429+3. Then I rebased those commits on top of latest
 esr68 branch, that's https://github.com/acatarineu/tor-
 browser/commits/30429+4. And finally, reordered some commits to address
 some review remaining comments and also fixed the search engines patch
 (Omnibox: Add DDG, Startpage, Disconnect, Youtube, Twitter...), that's
 branch https://github.com/acatarineu/tor-browser/commits/30429+5. I left
 the search engine fix for the end, and then I realized that there were
 some conflicts with esr68 branch, so that's why I only fixed it in the
 last branch (30429+5).

 While rebasing to esr68 branch (30429+3 -> 30429+4) there were several
 conflicts, although most of them were due to style changes. But I think it
 would be good to review them, for example:
 - Bug 21849: Don't allow SSL key logging
 (`gyp_vars['enable_sslkeylogfile']` was added)

 I also realized that in `Bug 8312: Remove "This plugin is disabled"
 barrier.` there is a `doc.getAnonymousElementByAttribute` but I do not see
 any defined `doc` variable. It's the same in 52, but I think in the
 previous version there was. So I added the `doc` definition, although I
 would have to test this to make sure if it works as intended.

 A question before comments: would it also make sense to try to upstream
 Bug #5741, with a different commit name and behind the --proxy-bypass-
 protection flag?

 Some comments:
 >please add --enable-proxy-bypass-protection to all mozconfigs
 Do you mean `.mozconfig-mac`, `.mozconfig-asan`, `.mozconfig` and
 `.mozconfig-mingw`? If so, isn't it already there?

 > 23b8e34d8fa64affdb265911ff586d8babf1a119 - should we not point to the
 latest Torbutton commit (especially as we have removed all the other
 Torbutton commit updates (rightly so))? otherwise okay
 I think so, but I kept the submodule change in a separate commit since
 it's currently it's in my personal branch. Would it be ok to make the last
 `WIP torbutton submodule change` commit a fixup when we have an "official"
 torbutton "esr68" branch?

 >  a8c48df07cc505bd45c764d223f6ff01de738f31 -- indentation (keep
 original):
 >
 >+  nsresult rv = GetOverrideStringBundleForLocale(
 >+  aSBS, uriString.get(), userAgentLocale.get(), aResult);
 `mach clang-format` is changing this one, should we keep the original
 indentation anyway?

 >There is no docshell/test/mochitest.ini in esr68 and we should not add
 one.
 Thanks. I also realized I removed I accidentally removed a test
 `[test_bug1507702.html]`, fixed that too.

 >Why GetComputedReferrer() and not GetOriginalReferrer()? Could you add an
 explaining comment here?
 I think `GetComputedReferrer()` is the one that preserves the current
 patch behaviour (e.g. takes into consideration referrer policy). Actually,
 when you mentioned I was not sure whether this was something intended. For
 example, with a noreferrer policy navigating through pages of the same
 origin will always clear `window.name`. But I saw #3414, so this actually
 seems to be the intended behaviour. I added a comment in the code.

 >You are not including components.conf in libmdns moz.build instead of
 patching it as you did in the provider case; we should have the same
 approach inboth cases (I am fine with just the moz.build one if we think
 that's enough)
 Ok, I reincluded `components.conf` in `moz.build`, and made the
 corresponding components.conf empty. Not sure if you meant this, or that
 we actually don't need to touch `libmdns` `components.conf`.

 > What is the reason to patch GetUser$Directory now while we did not have
 done so in the esr60 patch? (I guess we should follow Mozilla here and if
 not, please add some comment/explanation for that deviation)
 Not sure if you mean changing the static calls by the non-static ones. If
 so, this is 

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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201907, tbb-9.0-must-  |  Actual Points:
  nightly|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 Replying to [comment:15 mcs]:
 > Alex, we have a couple of questions about the rebasing process:
 >
 > 1. Do you want to rebase your rebased patches onto the tip of Mozilla's
 esr68 branch (or a recent tag) before Kathy and I do our rebasing work? I
 think that makes sense unless it turns out to be very time consuming.

 I will do that, after I address the requested changes here. Since I assume
 this is blocking for you, I will try to do it soon.

 > 2. Previous attempts to reorder the patches while rebasing have not gone
 well; it would be better if we preserved the order so for example the
 #4234 patch comes before the other updater-related patches such as the
 #16940 one. Is it OK if Kathy and I create a new branch with the rebased
 patches for the following tickets inserted in a similar place within the
 commit stream as for the ESR60 Tor Browser branches: #18900, #13252,
 #19121, #4234, #13379? The only downside that I see is that if you are
 working in parallel with us someone will need to cherry pick some patches
 from our branch along with all of your patches to create a consolidated
 branch (or do something else magical with git).

 I think this is fine, I don't see any issue with cherry-picking the
 updater patches to a more up to date consolidated branch later, if needed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201907, tbb-9.0-must-  |  Actual Points:
  nightly|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Alex, we have a couple of questions about the rebasing process:

 1. Do you want to rebase your rebased patches onto the tip of Mozilla's
 esr68 branch (or a recent tag) before Kathy and I do our rebasing work? I
 think that makes sense unless it turns out to be very time consuming.

 2. Previous attempts to reorder the patches while rebasing have not gone
 well; it would be better if we preserved the order so for example the
 #4234 patch comes before the other updater-related patches such as the
 #16940 one. Is it OK if Kathy and I create a new branch with the rebased
 patches for the following tickets inserted in a similar place within the
 commit stream as for the ESR60 Tor Browser branches: #18900, #13252,
 #19121, #4234, #13379? The only downside that I see is that if you are
 working in parallel with us someone will need to cherry pick some patches
 from our branch along with all of your patches to create a consolidated
 branch (or do something else magical with git).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201907, tbb-9.0-must-  |  Actual Points:
  nightly|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:13 gk]:
 > mcs/brade: to not lose this in the previous wall of text: I thought it
 could be helpful if you'd had a second look at commits
 >
 > 45072c2fea6a535a712ac0888f12f881393cccbd

 R.e. the `char16_t` question: a while ago, Mozilla changed
 `FormatStringFromName()` to take a
 `const char *` so the new code is good.

 R.e. gk's second comment: Kathy and I would prefer to always initialize
 `profileStatus` (seems safer).

 R.e. gk's last comment about possibly adding an another call to
 `CheckProfileWriteAccess()`: we think it is OK to skip this case.

 In the `ProfileErrorDialog()` function, please reinstate the `rv` check
 for the call to `sb->FormatStringFromName()` (I think it was lost during a
 previous rebase).

 In `nsToolkitProfileService::SelectStartupProfile()` the first call to
 `GetProfileByName()` is wrong. We should not be passing a path to that
 function (it looks like the ESR60 patch is wrong too). Instead, once we
 obtain `lf`, we should call `CheckProfileWriteAccess(lf)`. In other words,
 we can remove the entire chunk that contains the first call to
 `GetProfileByName()` as well as a call to
 `CheckProfileWriteAccess(profile)` and
 instead make the second call earlier.

 Also, Mozilla has made several changes to these files since Alex started
 the ESR68 TB rebasing work. Kathy and I would like to take another look at
 the patch after those changes have been accounted for.


 > 9d8ca4380e947c2097d0fd3554b1f3dad20de634

 It looks like event listeners are handled by via the `LEGACY_ACTORS`
 object. See the large comment near the beginning of
 `toolkit/modules/ActorManagerParent.jsm`. If that is correct, we should
 remove the `removeMessageListener()` and `removeEventListener()` calls
 from `browser/actors/AboutTBUpdateChild.jsm`.

 R.e. `isAboutTBUpdate()`, that is replaced by the `matches` property
 within the `LEGACY_ACTORS` object.

 R.e. `BrowserContentHandler.jsm` being moved to `EXTRA_PP_COMPONENTS`:
 that was part of the #4234 patch.

 Otherwise, this looks good. We will need to test it once the other updater
 patches have been rebased.

 > 5269df12586ac7e4e45803a0f1b8c15da9ef529a

 This looks good to us, although testing is required. The reason the
 `EXTRA_PP_JS_MODULES` change appears in this patch is because a similar
 change is included in the #4234 patch (which was applied before this
 patch).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201907, tbb-9.0-must-  |  Actual Points:
  nightly|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 mcs/brade: to not lose this in the previous wall of text: I thought it
 could be helpful if you'd had a second look at commits

 45072c2fea6a535a712ac0888f12f881393cccbd
 9d8ca4380e947c2097d0fd3554b1f3dad20de634
 5269df12586ac7e4e45803a0f1b8c15da9ef529a

 on acat's `30429` branch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  needs_revision
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201907  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * keywords:  TorBrowserTeam201907R => TorBrowserTeam201907
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:2 acat]:
 > == [rebased]

 Here are my comments, the hashes are from your `30249` branch:

 9510c9416ddd35a016ee2074dd58f927d97246c7 - not okay

 no need to comment out the maintenance related option, just remove it (and
 while we are at it, please remove the other unused options as well)

 please add `--enable-proxy-bypass-protection` to all mozconfigs

 4aec090126cd79289628b4403366c176714a4c77 - okay
 23b8e34d8fa64affdb265911ff586d8babf1a119 - should we not point to the
 latest Torbutton commit (especially as we have removed all the other
 Torbutton commit updates (rightly so))? otherwise okay

 22088a63f01c5526aedcafb3232f211a78ec9106 - okay (mobile)
 912ed4b07281ceebb67726b1785d12b37ab95b12 - okay (mobile)
 493b664f0fd1867559e51d6015c784e7c21a3259 - okay (mobile)
 34126c910efab560ff0d6923437c50758f8dc03f - we should merge that with the
 patches for #10760 I think (otherwise okay)
 bdf970dcdeeb276eccb9538b0d86dfee07ec5776 - okay
 5d3e47ad112820208dd894aaeb51497ab37caf65 - okay
 27fa31d4350e4248b0bfb35c51918955629a112a - okay
 b7c8b9e0b641cdfeef8ac2adc5188c340374 - okay
 f9957d4fd3f164be68adcd32206c09cb6f59a16d - could you do a `git commit
 --squash` here with commit 4aec090126cd79289628b4403366c176714a4c77;
 please add the Trac bug number to this pref flip so we get easily the
 context and move the pref flip to the fingerprinting section of `000-tor-
 browser.js`
 55367b7e2edbaf55f1142140b2cb9ec9b9247bec - okay
 9909eeb95cea7fa84bcd45bc0c4c22d83e17 - okay
 45072c2fea6a535a712ac0888f12f881393cccbd - (mcs/brade should have a second
 look at this patch) I wondered how we ever settled at a `const char16_t*`
 first given the signature of `FormatStringFromName()` but I agree that
 using `const char*` seems more intuitive.

 `+  ProfileStatus profileStatus = PROFILE_STATUS_OK;` <- do we need to
 assign `PROFILE_STATUS_OK` here, wouldn't it be enough to just do
 `ProfileStatus profileStatus;` given that you do `+  aProfileStatus =
 PROFILE_STATUS_OK;` and don't assign that in `SelectUpdateProfile` either?

 There is in `nsToolkitProfileService`:
 {{{
GetProfileByDir(lf, localDir, getter_AddRefs(profile));

 if (profile && mIsFirstRun && mUseDedicatedProfile) {
 }}}
 Should we have the usual `CheckProfileWriteAccess()` call here as well or
 did you think this is a non-issue as we are there "generally" from an app
 initiated restart, as the comment says.

 a8c48df07cc505bd45c764d223f6ff01de738f31 -- indentation (keep original):
 {{{
 +  nsresult rv = GetOverrideStringBundleForLocale(
 +  aSBS, uriString.get(), userAgentLocale.get(), aResult);
 }}}
 `// Build Torbutton file URI string by starting from the profiles
 directory.` <- It's not the profiles directory anymore

 Making `dirProvider` a `RefPtr` seems okay to me.

 Should `general.useragent.locale` be `intl.locale.requested` (I guess this
 should have been the case for Tor Browser 8 already, but well...)

 2d2a55296e255f9b502d0aa9eb70d4822a1bdd0e - okay
 9ec12a9075a87f1a1d446200ca4f64f88ef8466f - okay [we should upstream that
 one, bug 967812 has code parts]
 5b585b0633d5359504542b0fb05b599cb879a883 - okay
 630b395081dc68828d8f55ea41c71297b123bb87 - okay
 73e8dc78ddb3caf7b7dde8df2ea15dd9898cccac - not needed, see bug 1434772
 8295e48bb7d948fd8e85cbc9f5ffe7e9e0d9ea6b - okay
 d9cc80636e3dfcdf28bb368b416508402e9b9f9a - okay
 237124a540877734cc15a60de613f29b064f3799 - okay
 a4282bea59a32dba0a17f3d31e6f7f6094a98eac - not okay

 There is no docshell/test/mochitest.ini in esr68 and we should not add
 one.

 `+const kTestPath = "/tests/docshell/test/";` needs adaptation to new path

 Why `GetComputedReferrer()` and not `GetOriginalReferrer()`? Could you add
 an
 explaining comment here?

 a3acbf09d562e14f9e67f91db7a12bd185058b18 - not needed anymore with
 `--enable-proxy-bypass-protection` set
 4bd0f7037b7a89a9ec95e540f58ebcb5cd74bd07 - okay
 5011133b08cfdfbb5e6ad3ff03b1d230bb206608 - not okay

 The `AndroidCastProvider` part needs to get ripped out in components.conf
 as well, as things might break otherwise if we don't include it in
 moz.build (which we should not and your patch makes sure)

 You are not including `components.conf` 

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

[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:  TorBrowserTeam201906R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:5 gk]:
 > Replying to [comment:2 acat]:
 > > * Android: should we do this after desktop patches? here or in a
 separate ticket?
 >
 > We should do it in parallel or better: not blocking the rebasing work on
 desktop patches. sysrqb will pick this up and probably decide whether to
 use a child bug or have the rebase in this ticket.
 >

 I opened #31010 for Android. I'll update that ticket and let this one
 remain focused on the desktop and shared code patches.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:  TorBrowserTeam201906R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by acat):

 I added some more patches in https://github.com/acatarineu/tor-
 browser/commits/30429+1. It's onboarding and onion security expectations
 ones. I think there is one from the "onion security expectations" that is
 not needed anymore. Changes in the list of commits:

 == [rebased]
 {{{
 + d92980f74016 Bug 29768: Introduce new features to users
 + 523a66a1affa Bug 27486 Avoid about:blank tabs when opening onboarding
 pages.
 + ee4f40d85a8b Bug 26962 - implement new features onboarding (part 1).
 + 98b1707f1930 Bug 26961: New user onboarding.
 + 651e4ef7de3e Bug 23247: Communicating security expectations for .onion
 }}}

 == [onboarding]
 {{{
 - d92980f74016 Bug 29768: Introduce new features to users
 - 523a66a1affa Bug 27486 Avoid about:blank tabs when opening onboarding
 pages.
 - ee4f40d85a8b Bug 26962 - implement new features onboarding (part 1).
 - 98b1707f1930 Bug 26961: New user onboarding.
 }}}

 == [onion security expectations]
 {{{
 - 988d41acfaca Bug 26456: HTTP .onion sites inherit previous page's
 certificate information
 - 651e4ef7de3e Bug 23247: Communicating security expectations for .onion
 }}}


 == [DROP? might not be needed -> check]
 {{{
 + 988d41acfaca Bug 26456: HTTP .onion sites inherit previous page's
 certificate information
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:  TorBrowserTeam201906R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by acat):

 >>Onion security expectations: a couple of patches, depending on
 availability, perhaps pospeselr could work on these?
 >What are the issues here? Could you file a new bug to track that work?

 I left them for the end after a quick look, but I just tried again and it
 seems not so much work. So I can work on these after working on
 onboarding.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:  TorBrowserTeam201905R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:2 acat]:

 [snip]

 Okay, let me start by replying to the ToDos:

 > Some TODOs:

 [snip]

 > * Integrate in tor-browser-build: is the toolchain ready? would it "just
 work" to change the firefox repo to point to this one?

 No, it is not yet. The current branch is `linux_esr68_v3` in my repo (with
 probably a bunch of `linux_esr68_v$` to follow) but there are still build
 requirements missing (`nodejs` is the next one to add)

 [snip]

 > * Updater: will mcs/brade work on these?

 Yes.

 > * Onboarding: as described in #28822, this needs to be ported, since
 onboarding (bootstrapped) extension is not there anymore. I could take a
 look at this one.

 Sounds good.

 > * Onion security expectations: a couple of patches, depending on
 availability, perhaps pospeselr could work on these?

 What are the issues here? Could you file a new bug to track that work?

 > * Decide what to do with patches from #28711.

 Ideally we could backport them and have some knowledgeable Mozilla person
 looking over the result.

 [snip]

 > * Backport https://bugzilla.mozilla.org/show_bug.cgi?id=1330467 or wait
 if it's included in 68.

 It seems we need to backport them, alas. :( They got a minus for beta
 (that is esr68) inclusion.

 > * Android: should we do this after desktop patches? here or in a
 separate ticket?

 We should do it in parallel or better: not blocking the rebasing work on
 desktop patches. sysrqb will pick this up and probably decide whether to
 use a child bug or have the rebase in this ticket.

 [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] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

[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:  TorBrowserTeam201905R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  TorBrowserTeam201905 => TorBrowserTeam201905R
 * 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] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201905  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by acat):

 Until Tor Launcher is integrated, it needs explicit `TOR_CONTROL_PORT` for
 New Identity to work:

 {{{
 TOR_CONTROL_PORT=9151 TOR_CONTROL_PASSWD='"mypassword"' ./firefox
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201905  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by acat):

 Using commits `47aefe747950..e9b8de8c8d6a` from tor-
 browser-60.7.0esr-9.0.1.

 Most of the desktop patches are rebased in https://github.com/acatarineu
 /tor-browser/commits/30429.

 Below you can find the list commits/patches split into several
 "categories". Order of commits was not preserved in all cases, but the set
 of the commits of all categories below should be the same as above
 (`47aefe747950..e9b8de8c8d6a`).

 In that branch there is a WIP #10760 commit adding the browser parts of
 the torbutton integration, and also temp. moving the torbutton submodule
 to a WIP branch https://github.com/acatarineu/torbutton/tree/10760. This
 of course will have to change once/if torbutton migration proposal is
 approved and #10760 changes accepted. Most (or all?) torbutton features
 should be working with this.

 I'm currently building with `mach build && mach package` and disabling
 tor-launcher (`--disable-tor-launcher`), since AFAIK it would still not
 work without #29197. I could also not run tbb-tests (although I did not
 try very hard yet). To launch Tor, I'm doing it manually with
 {{{
 tor HashedControlPassword $(tor --quiet --hash-password mypassword)
 SocksPort 9150 ControlPort 9151 HTTPTunnelPort 0 DataDirectory
 /tmp/tortemp
 }}}

 then launching the built browser with
 {{{
 TOR_CONTROL_PASSWD='"mypassword"' ./firefox
 }}}

 NoScript addon can be manually installed (and enabled on private windows,
 see #28896) and then security levels UI should work fine.

 Some TODOs:

 * Port tor-launcher to 68: at least #29197, perhaps more.
 * Integrate in tor-browser-build: is the toolchain ready? would it "just
 work" to change the firefox repo to point to this one?
 * Be able to run tbb-tests (and make them green).
 * Updater: will mcs/brade work on these?
 * Onboarding: as described in #28822, this needs to be ported, since
 onboarding (bootstrapped) extension is not there anymore. I could take a
 look at this one.
 * Onion security expectations: a couple of patches, depending on
 availability, perhaps pospeselr could work on these?
 * Decide what to do with patches from #28711.
 * Verify 'might not be needed' patches.
 * Backport https://bugzilla.mozilla.org/show_bug.cgi?id=1330467 or wait if
 it's included in 68.
 * Android: should we do this after desktop patches? here or in a separate
 ticket?

 == [rebased]
 {{{
 724044f7deae Bug 28044: Integrate Tor Launcher into tor-browser
 7b9d68ac9f9a Bug 28369: stop shipping pingsender executable
 b5ce43598da9 Bug 27503: Disabling accessibility on Windows breaks screen
 readers
 350fb9de802c Bug 25658: Replace security slider with security level UI
 784829dd21ce Bug 29120: Enable media cache in memory
 4791a84c69f2 Bug 28885: notify users that update is downloading
 0db452ba7d90 Bug 12885: Windows Jump Lists fail for Tor Browser
 9a64fd2b6786 Bug 25702: Update Tor Browser icon to follow design
 guidelines ---[Notes: app.update.download.backgroundInterval is not there
 anymore; this changes onboarding assets]
 000879d8c0d6 Bug 27623 - Export MOZILLA_OFFICIAL during desktop builds
 cf13c54c3725 Bug 26146: Spoof HTTP User-Agent header for desktop platforms
 ---[Move to pref overrides?]
 ae2a89c7e1e7 Bug 26048: potentially confusing "restart to update" message
 ---[Did not find a simple way to do this with Fluent, so reused another
 DTD entitity that is still there...]
 6bcc9d3aea2d Bug 24056: Use en-US strings in HTML forms
 e8833081b428 Bug 27082: enable a limited UITour
 f6cfb16dcbab Bug 26514 - intermittent updater failures on Win64 (Error 19)
 dcb5386e668d Bug 26353: Prevent speculative connect that violated FPI.
 898b402c2458 Bug 26045: Add new MAR signing keys
 1ef28dca0a8f Bug 21537: Tests for secure .onion cookies
 d5cf5a3f1e89 Bug 21537: Mark .onion cookies as secure
 97237186c6b5 Bug 22548: Firefox downgrades VP9 videos to VP8.
 0a793927d7b0 Bug 23104: Add a default line height compensation
 8ccd532c1007 Bug 21830: Copying large text from web console leaks to /tmp
 75ea009946e5 Bug 21321: Add test for .onion whitelisting
 7fe43a8ecdeb Bug 21431: Clean-up system extensions shipped in Firefox 52
 a347487a1d1e Bug 16285: Exclude ClearKey system for now ---[There's a new
 MOZ_EME_WIN32_ARTIFACT, it should not be enabled.]
 7162a6dd03b1 Bug 21907: Fix runtime error on CentOS 6 ---[It seems CentOS
 6 i

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

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201905  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * priority:  High => Very High


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam201905
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We need to start rebasing our patches against Firefox 68. This is the
 ticket that tracks the whole effort.

 It's helpful how we did it the last time: comment:6:ticket:25543. As
 mentioned there https://torpat.ch/ is a very valuable resource. It might
 need updating, though (which we should do while we are at it, or point
 Arthur to the things that need to get fixed).

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