Closed Bug 1896449 Opened 5 months ago Closed 2 months ago

search.json.mozlz4 contains some hardcoded path data, making it not-portable

Categories

(Firefox :: Profile Backup, task, P3)

task

Tracking

()

RESOLVED FIXED
130 Branch
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.

Assignee: nobody → mconley

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

Status: NEW → ASSIGNED

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.

Flags: needinfo?(standard8)
Flags: needinfo?(standard8)
Blocks: 1910968
Pushed by mconley@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3c3abc9151ee Recompute verification hashes for non-default engines during backup recovery. r=backup-reviewers,search-reviewers,Standard8,kpatenio
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 130 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: