In #25543 (moved), the tor-browser patches were rebased from 52ESR onto 60ESR. Here we need the tor-browser patches rebased onto FF61 because that is what the TBA patches are based on.
This should be significantly easier than #25543 (moved).
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
Here's my branch, which I created by rebasing tor/tor-browser-60.0.1esr-8.0-1 (30544586f8a98e985e0038b2e905bfddb14e999e) onto a recent gecko-dev/beta (c432661a14b1ad331e22e2524ae8d57f9161884f):
I left out three updater patches that are complex to rebase and I think won't be needed for Android in any case (please correct me if I'm wrong!). I also squashed the fixup commits.
Here's what happened to each patch:
C = cherry-pickedF = fixed upU = upstreamed? = left out for now (updater patches)C 30544586f8a9 fixup! TB4: Tor Browser's Firefox preference overrides.F b135c59f65db Fix MAR generation bashismC 1ba7b6b25113 fixup! TB4: Tor Browser's Firefox preference overrides.C b589ec74c427 Bug 20283: Tor Browser should run without a `/proc` filesystem.C 3a6cb718e815 Bug 21537: Tests for secure .onion cookiesC 58e4a739a6ed Bug 21537: Mark .onion cookies as secureU 440d2fe1b6f4 Bug 1441327 - Allow for seccomp filtering of socket(AF_INET/AF_INET_6) calls on Linux when using UNIX Domain Sockets for SOCKS Proxy. r=bagderC ed1a45a69d15 Bug 22548: Firefox downgrades VP9 videos to VP8.C 550d0bae6d40 Bug 24398: Plugin-container process exhausts memoryF 3206814bc291 Bug 23104: Add a default line height compensationC 53f7ab7d844a Bug 24052: Handle redirects by blocking them earlyC 5e0170a7ca05 Bug 13398: at startup, browser gleans user FULL NAME (real name, given name) from O/SC c5544f727e46 Bug 21830: Copying large text from web console leaks to /tmpC 962babebfc5e Bug 21321: Add test for .onion whitelistingF d18befdee332 Bug 21431: Clean-up system extensions shipped in Firefox 52C fe68460a72cd Bug 21569: Add first-party domain to Permissions keyC 2aa950923c66 Bug 16285: Exclude ClearKey system for nowC 32da0487944c Bug 21907: Fix runtime error on CentOS 6C d010f98a92fe Bug 21849: Don't allow SSL key loggingF d29c1ddb254d Bug #5741: Prevent WebSocket DNS leak.F c67a0c07fd5b Bug 14970: Don't block our unsigned extensionsF 3549c5324dda Omnibox: Add DDG, Startpage, Disconnect, Youtube, Twitter; remove Amazon, eBay, bingC e984b8c54c75 Bug 23916: Add new MAR signing key? 70989b5211d8 Bug 16940: After update, load local change notes.? 189164e100db Bug 13379: Sign our MAR files.? 4b4dcd40abae Bug 4234: Use the Firefox Update Process for Tor Browser.C 7ca562c26856 Bug 25909: disable updater telemetryC 39f10aaa10ef Bug 19121: reinstate the update.xml hash checkC 9a3bb35800d5 Bug 19121: reinstate the update.xml hash checkF a4ac08e62457 Bug 13252: Do not store data in the app bundleC cab08be85615 Bug 21724: Make Firefox and Tor Browser distinct macOS appsC 75d638dddd7d Bug 18912: add automated tests for updater cert pinningC b95e30974e71 Bug 18900: updater doesn't work on Linux (cannot find libraries)C 716067b4c679 Bug 11641: change TBB directory structure to be more like Firefox'sC 4e0aed04f7f7 Bug 9173: Change the default Firefox profile directory to be TBB-relative.C 71a812c584aa Bug 19890: Disable installation of system addonsC 17367581443f Bug 19273: Avoid JavaScript patching of the external app helper dialog.C 4da1d08fb2e2 Bug 18923: Add a script to run all Tor Browser specific testsC 612aefdabd9b Regression tests for #2874: Block Components.interfaces from contentC 27fa6ab6fa2b Bug 18821: Disable libmdns for Android and DesktopC 40752ee655eb Bug 18800: Remove localhost DNS lookup in nsProfileLock.cppC cc9862c27fd5 Bug 18799: disable Network TicklerC 5823d75f953a Bug 16620: Clear window.name when no referrer sentC 48b1c08e1fff Bug 16441: Suppress "Reset Tor Browser" prompt.C 6734d99f40b0 Bug 14392: Make about:tor behave like other initial pages.C 006dffb468ee Bug 2176: Rebrand Firefox to TorBrowserC 16a1bcef4e15 Bug 18995: Regression test to ensure CacheStorage is disabled in private browsingC c5b57b1bf1df Regression tests for "Omnibox: Add DDG, Startpage, Disconnect, Youtube, Twitter; remove Amazon, eBay, bing"C 6b35333f3a3a Regression tests for TB4: Tor Browser's Firefox preference overrides.C 93a8e5d1b523 Regression tests for Bug #2950: Make Permissions Manager memory-onlyC 1dc1a4f7fedc Bug 12620: TorBrowser regression tests folderC b6d8bf568ba6 Bug 14631: Improve profile access error msgs (strings).C 10ac5a7be31f Bug 14631: Improve profile access error messages.C 87cb0833ffdd Bug 14716: HTTP Basic Authentication prompt only displayed onceC ccebcbb95267 Bug 13028: Prevent potential proxy bypass cases.C dfd201a96767 Bug 16439: remove screencasting code.F e0cb606a47ac Bug 2874: Block Components.interfaces from contentC 58a737f021b2 Bug 12974: Disable NTLM and Negotiate HTTP AuthC fe1e6ce7f8d8 Bug 10280: Don't load any plugins into the address space.C 837f8e888cf5 Bug 8312: Remove "This plugin is disabled" barrier.C 1cbd34d3b0b8 Bug 3547: Block all plugins except flash.F 0e8dbb37c450 TB4: Tor Browser's Firefox preference overrides.C 4bdb543b0ae7 TB3: Tor Browser's official .mozconfigs.
Initial testing with rebasing this branch on top of my current #25741 (moved) branch is looking good! Thanks!
I added two fixups on top of my branch[0] that disable (ifdef-out) unused code which cause build failure when compiled with -Werror. This allows for running Try builds[1][2]. The HEAD commit is needed because it's possible mozilla-central and mozilla-beta don't have any commits by ffxbld within the last 500 commits (as is currently the situation).
I'm trying to get the Tor Browser mochitests working - but I won't spend too much time on this. I think I'm hitting a local issue.
Okay, here comes the review. I think MAR files and the signing machinery we have won't play a role for Android (see: #26242 (moved) for our update strategy), thus we can ignore all the signing related patches, I agree. I've been a bit more agressive when reviewing your changes. Here is all I got:
c7036c883efebaf0ee6d27285e7a5f9d0abe8eb8 -- good (4bdb543b0ae7)
2078afc6814a8f0303d9a83c050c068bda704ce3 -- not okay (0e8dbb37c450)
> +// Disable window.Components shim (substitue for https://bugs.torproject.org/2874)> +pref("dom.use_components_shim", false);
F e0cb606a47ac Bug 2874: Block Components.interfaces from content <- I was confused by that because there is no bug 2874 related patch anymore. So, better "O" I guess.
I think that can go as the patch got upstreamed in bug 967812 (it seems I overlooked that by the review for ESR60). Or do we want to keep the test because the upstreamed patch does not contain tests? In that case I am fine with keeping it for now but we should get the test on the uplift
radar in this case (why is it marked as tbb-no-uplift?).
Where are the changes in nsToolkitProfileService.cpp etc. coming from? I fail to find them on m-c. It seems to me we don't want to differe more than needed from Mozilla here.
f4c2dd434d4bb4aa5cbe4937c6f4e5f85eef74f9 -- okay (716067b4c679)
3f7ac7eb4d1fc0e66b3105fa105c639aea134733 -- not okay (b95e30974e71)
not needed for android as it is an updater patch
a5a2ed6a11b3b1042e02f568f61f8de45a715f49 -- not okay (75d638dddd7d)
Two things we should think about while preparing the new branch:
How would the naming scheme for our mobile branches look like? Currently we have "tor-browser-
ESRVERSION−
TORBROWSER_MAJOR_VERSION-$BRANCH_NUMBER" which points to the second question:
What version number for Tor Browser for Android do we start with? Especially given that we are tracking Mozilla release and not esr anymore? Should we start over with 1.0?
Trac: Status: needs_review to needs_revision Keywords: TorBrowserTeam201806R deleted, TorBrowserTeam201806 added
Two things we should think about while preparing the new branch:
How would the naming scheme for our mobile branches look like? Currently we have "tor-browser-
ESRVERSION−
TORBROWSER_MAJOR_VERSION-$BRANCH_NUMBER" which points to the second question:
I don't see a problem using this same format. Unfortunately, as mentioned before, TB Android will begin overlapping with TB Desktop next year. So, either Desktop begins following mozilla-release at that time (next ~April), or we choose a unique name.
What version number for Tor Browser for Android do we start with? Especially given that we are tracking Mozilla release and not esr anymore? Should we start over with 1.0?
Originally I thought we would use the same naming scheme, because "these are both tor browser", but after thinking about this more we should probably start at 1.0. There are 7 or 8 releases between every ESR, so the version would become very confusing. I think if we follow Mozilla's alpha, beta, stable then we can start at 1.0 and we'll reach 8.0 by next April.
Trac: Owner: sysrqb to arthuredelstein Status: needs_revision to assigned
Okay, here comes the review. I think MAR files and the signing machinery we have won't play a role for Android (see: #26242 (moved) for our update strategy), thus we can ignore all the signing related patches, I agree. I've been a bit more agressive when reviewing your changes. Here is all I got:
c7036c883efebaf0ee6d27285e7a5f9d0abe8eb8 -- good (4bdb543b0ae7)
2078afc6814a8f0303d9a83c050c068bda704ce3 -- not okay (0e8dbb37c450)
{{{
+// Disable window.Components shim (substitue for https://bugs.torproject.org/2874)
+pref("dom.use_components_shim", false);
}}}
"substitue" and could you mention the Mozilla bug number (1448048)?.
Looks like that bug has stalled, but in principle that telemetry proposed there would have been useful for the justifying final removal of the components shim. Since that's no longer needed, I removed the [tor 2874] whiteboard tag.
F e0cb606a47ac Bug 2874: Block Components.interfaces from content <- I was confused by that because there is no bug 2874 related patch anymore. So, better "O" I guess.
I think that can go as the patch got upstreamed in bug 967812 (it seems I overlooked that by the review for ESR60). Or do we want to keep the test because the upstreamed patch does not contain tests? In that case I am fine with keeping it for now but we should get the test on the uplift
radar in this case (why is it marked as tbb-no-uplift?).
I'm inclined to keep it so we can propose uplifting a test. I removed the tbb-no-uplift keyword from #2950 (closed).
Where are the changes in nsToolkitProfileService.cpp etc. coming from? I fail to find them on m-c. It seems to me we don't want to differe more than needed from Mozilla here.
In our original patch, the static keyword has been removed from some functions in nsXREDirProvider.h and so all invocations need to be modified. Unfortunately some additional invocations appeared in other files so these need to be modified as well.
f4c2dd434d4bb4aa5cbe4937c6f4e5f85eef74f9 -- okay (716067b4c679)
3f7ac7eb4d1fc0e66b3105fa105c639aea134733 -- not okay (b95e30974e71)
not needed for android as it is an updater patch
Removed.
a5a2ed6a11b3b1042e02f568f61f8de45a715f49 -- not okay (75d638dddd7d)
6dad47dd282fe46e888c56e3067869bf99cec47f -- not okay (9a3bb35800d5)
not needed for android as it is an updater patch
Removed.
1478cf4bf40f50144ef053d0e27d5e39946c11ba -- not okay (39f10aaa10ef)
not needed for android as it is an updater patch
Removed.
026597a98e8a75442bc59978d7f2b43bc98c0e2d -- okay (7ca562c26856)
013a9bd751a57e3b2d28adebe4c742b2300624a8 -- not okay (e984b8c54c75)
not needed for android as it is an updater patch
Removed.
c42570e07aaae5883cea1c05ff685b78e3c4de33 -- okay (3549c5324dda)
d5acddaef9c2884a3216febefa77389eb12d4c7e -- not okay (c67a0c07fd5b)
{{{
// Make sure Torbutton, TorLauncher, EFF's HTTPS-Everywhere and meek
if (XPIDatabase.mustSign(addon.type) &&
}}}
One comment line got lost during the rebase.
Two things we should think about while preparing the new branch:
How would the naming scheme for our mobile branches look like? Currently we have "tor-browser-
ESRVERSION−
TORBROWSER_MAJOR_VERSION-$BRANCH_NUMBER" which points to the second question:
What version number for Tor Browser for Android do we start with? Especially given that we are tracking Mozilla release and not esr anymore? Should we start over with 1.0?
A random idea: what about using the same numbers as Firefox? Like Tor Browser Android 61.0, etc.
Trac: Status: needs_revision to needs_review Keywords: TorBrowserTeam201806 deleted, TorBrowserTeam201806R added
79289c71dc16e3064e1ceb17fb1900e0d08273d8 -- not okay (4e0aed04f7f7)
Where are the changes in nsToolkitProfileService.cpp etc. coming from? I fail to find them on m-c. It seems to me we don't want to differe more than needed from Mozilla here.
In our original patch, the static keyword has been removed from some functions in nsXREDirProvider.h and so all invocations need to be modified. Unfortunately some additional invocations appeared in other files so these need to be modified as well.
rv = mDirProvider.GetUserAppDataDirectory(getter_AddRefs(file));
}}}
essentially reverting bug 1443080 and deviating from the fix pattern using the GetSingleton()-approach?
We're reverted that piece of 1443080 because in our patch, the methods are no longer static. (That bug was removing instance calls to static functions.) We could use either pattern, but because mDirProvider is already available and used commonly in that file it seemed OK.