[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #28640 [Applications/Tor Browser]: System addon does not override app-profile addon
#28640: System addon does not override app-profile addon
----------------------------------------------+--------------------------
Reporter: sysrqb | Owner: tbb-team
Type: defect | Status: new
Priority: Very High | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: tbb-mobile, TorBrowserTeam201811 | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
----------------------------------------------+--------------------------
Changes (by gk):
* cc: mcs, brade (added)
* keywords: tbb-mobile => tbb-mobile, TorBrowserTeam201811
* status: needs_information => new
Comment:
Replying to [comment:2 sysrqb]:
> I think it is intentional that the app profile extensions override the
system addon: [https://gitweb.torproject.org/tor-
browser.git/tree/toolkit/mozapps/extensions/internal/XPIProvider.jsm#n2105
in XPIProvider] - at least this is how I am reading it.
That's actually okay I think. The bug here is that the there is an
integral extension, which we don't ship anymore compared to the previous
bundle, still available after the update and not deleted.
For Linux/Windows we get that essentially for free as the profile is
included inside of the bundle and the logic determining which items to
remove/replace is running across the profiles on those platforms as well.
For macOS the case is different as we needed to get the profile outside of
the bundle directory for code signing purposes (see: #13252, and note that
we plan to do so for Linux and Windows, too, as there are a bunch of bugs
with our current way of doing things on those platforms, see: #18367 and
#18369). We solved that problem but I currently can't find the details,
mcs/brade might know. That in turn might help to find a good solution for
Android case and/or might help thinking through whether desktop platforms
would be affected the same once we transition to a built-in Torbutton for
them, too.
> I wonder if we should do something slightly hacky. In the
`PostUpdateHandler`, when the system extensions are copied into the
`features/` dir, we check if the same addon is already installed in the
profile, and we uninstall it if it is found.
Sounds fine with me if we don't fine a better plan.
> (I don't know how to initiate an uninstall of an addon from Java -
[https://gitweb.torproject.org/tor-
browser.git/tree/mobile/android/chrome/content/aboutAddons.js#n344 the
javascript is context sensitive] - plus it requires another restart before
it is it fully uninstalled, but that's another problem).
Yeah, le't not go that route.
> The third problem is preferences.json isn't copied from the apk into the
app's data directory. I think this is because the the app
[https://gitweb.torproject.org/tor-
browser.git/tree/mobile/android/base/java/org/mozilla/gecko/distribution/Distribution.java#n520
sets a preference] (`distribution_state`) when initialization completes,
and then it [https://gitweb.torproject.org/tor-
browser.git/tree/mobile/android/base/java/org/mozilla/gecko/distribution/Distribution.java#n491
never copies new files] from newer APKs during an update.
That's annoying. I think we should make exceptions for the files we care
about. Or we could just put some logic in the `PostUpdateHandler` here as
well.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28640#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs