search.json.mozlz4 contains some hardcoded path data, making it not-portable
Categories
(Firefox :: Profile Backup, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox130 | --- | fixed |
People
(Reporter: mconley, Assigned: mconley)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fidefe-device-migration])
Attachments
(1 file)
Standard8 pointed out that the search.json.mozlz4 file contains some information that involves the absolute path to the profile directory. This means that if a user has some kind of third-party search engine set, this won't restore correctly. We'll need to modify the search.json.mozlz4 during recovery in order to make this work properly.
Updated•5 months ago
|
Assignee | ||
Updated•3 months ago
|
Assignee | ||
Comment 1•3 months ago
|
||
Assignee | ||
Comment 2•3 months ago
|
||
Hey Mark,
I'm trying to figure out the best way to do this. The easiest is probably to re-use SearchUtils.getVerificationHash
to generate the hash, but this presumes that I'm running in the same profile that search.json.mozlz4
belongs to... which means that I need to launch the profile in order use this method.
We have a "post-recovery" phase where the BackupService can run some steps inside of the recovered profile after launching, but presumably this would be after the search service initializes. Is it advisable to manipulate search.json.mozlz4
after the initialization? Feels kind of flimsy. Or is it better to use the SearchService mechanisms to revive custom engines after recovery? My worry there is that we open up a new way for search hijackers to
Assignee | ||
Comment 3•3 months ago
|
||
I spoke to standard8 and mcheang out-of-band, and we agreed that having getVerificationHash
accept an optional profile directory as a second argument seems like it'd work.
Assignee | ||
Comment 4•3 months ago
|
||
ni'ing Standard8 for https://phabricator.services.mozilla.com/D215963#7449935
Updated•2 months ago
|
Comment 6•2 months ago
|
||
bugherder |
Description
•