mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-22 01:35:35 +00:00
Bug 1634700 - Always use latest generation_time in MLBF blocklist updates r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D73464
This commit is contained in:
parent
aa423d1002
commit
eb8be1efed
@ -1370,7 +1370,16 @@ this.ExtensionBlocklistMLBF = {
|
||||
// (provided that the client has been built with it included).
|
||||
let hash = record?.attachment.hash;
|
||||
if (this._mlbfData && hash && this._mlbfData.cascadeHash === hash) {
|
||||
// Not changed, let's re-use it.
|
||||
// MLBF not changed, save the efforts of downloading the data again.
|
||||
|
||||
// Although the MLBF has not changed, the time in the record has. This
|
||||
// means that the MLBF is known to provide accurate results for add-ons
|
||||
// that were signed after the previously known date (but before the newly
|
||||
// given date). To ensure that add-ons in this time range are also blocked
|
||||
// as expected, update the cached generationTime.
|
||||
if (record.generation_time > this._mlbfData.generationTime) {
|
||||
this._mlbfData.generationTime = record.generation_time;
|
||||
}
|
||||
return this._mlbfData;
|
||||
}
|
||||
const {
|
||||
|
@ -128,6 +128,40 @@ add_task(async function public_api_uses_mlbf() {
|
||||
// Note: Blocklist collection and attachment carries over to the next test.
|
||||
});
|
||||
|
||||
// Verifies that the metadata (time of validity) of an updated MLBF record is
|
||||
// correctly used, even if the MLBF itself has not changed.
|
||||
add_task(async function fetch_updated_mlbf_same_hash() {
|
||||
const recordUpdate = {
|
||||
...MLBF_RECORD,
|
||||
generation_time: MLBF_RECORD.generation_time + 1,
|
||||
};
|
||||
const blockedAddonUpdate = {
|
||||
id: "@blocked",
|
||||
version: "1",
|
||||
signedDate: new Date(recordUpdate.generation_time),
|
||||
};
|
||||
|
||||
// The blocklist already includes "@blocked:1", but the last specified
|
||||
// generation time is MLBF_RECORD.generation_time. So the addon cannot be
|
||||
// blocked, because the block decision could be a false positive.
|
||||
Assert.equal(
|
||||
await Blocklist.getAddonBlocklistState(blockedAddonUpdate),
|
||||
Ci.nsIBlocklistService.STATE_NOT_BLOCKED,
|
||||
"Add-on not blocked before blocklist update"
|
||||
);
|
||||
|
||||
await AddonTestUtils.loadBlocklistRawData({ extensionsMLBF: [recordUpdate] });
|
||||
// The MLBF is now known to apply to |blockedAddonUpdate|.
|
||||
|
||||
Assert.equal(
|
||||
await Blocklist.getAddonBlocklistState(blockedAddonUpdate),
|
||||
Ci.nsIBlocklistService.STATE_BLOCKED,
|
||||
"Add-on blocked after update"
|
||||
);
|
||||
|
||||
// Note: Blocklist collection and attachment carries over to the next test.
|
||||
});
|
||||
|
||||
// Checks the remaining cases of database corruption that haven't been handled
|
||||
// before.
|
||||
add_task(async function handle_database_corruption() {
|
||||
|
Loading…
Reference in New Issue
Block a user