Extraneous elements in blocklist XML causing blocks to not work

RESOLVED FIXED

Status

()

Toolkit
Blocklisting
RESOLVED FIXED
8 months ago
8 months ago

People

(Reporter: jorgev, Unassigned)

Tracking

51 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 months ago
This was reported to me over IRC and I haven't been able to verify it.

I updated some blocklist entries for bug 1337126. Specifically, the last two sets of Flash blocks, the latest being bug 1330086. The updated blocks now have some extra nodes in the XML, as can be seen on DXR: https://dxr.mozilla.org/mozilla-central/source/browser/app/blocklist.xml#2582

    <pluginItem blockID="p1494" os="">
      <match exp="" name="name"/>
      <match exp="(NPSWF32.*\.dll)|(NPSWF64.*\.dll)|(Flash\ Player\.plugin)" name="filename"/>
      <match exp="" name="description"/>
      <infoURL>https://get.adobe.com/flashplayer/</infoURL>
      <versionRange maxVersion="24.0.0.186" minVersion="23.0.0.207" severity="0" vulnerabilitystatus="1"/>
    </pluginItem>

Note the empty match nodes for `name` and `description`, and the empty `os` attribute.

A user claims these changes are making the Flash block to fail.
(Reporter)

Comment 1

8 months ago
Kamil, can you check if bug 1330086 is still working correctly?
Flags: needinfo?(kjozwiak)
For sure empty OS, name and description are a problem. Using the kinto-admin you should be able to get rid of them.
(In reply to Jorge Villalobos [:jorgev] from comment #1)
> Kamil, can you check if bug 1330086 is still working correctly?

Yup, I'll go through the blocklists in bug#1330086 shortly and make sure they're working. Could this possibly be related to bug#1331489?
(Reporter)

Comment 4

8 months ago
(In reply to Kamil Jozwiak [:kjozwiak] from comment #3)
> Yup, I'll go through the blocklists in bug#1330086 shortly and make sure
> they're working. Could this possibly be related to bug#1331489?

I don't think so. bug 1337126 is the first change we make since the move to kinto.
According to the xml-verify we have 6 impacted plugins:
- p1495
- p1494
- p1422
- p1421
- p1420
- p1419
- p1274
https://firefox.settings.services.mozilla.com/v1/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/47.0/

We have a fix pending for review that you can try here:

https://firefox.settings.services.mozilla.com/v1/preview/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/47.0/
(In reply to Jorge Villalobos [:jorgev] from comment #1)
> Kamil, can you check if bug 1330086 is still working correctly?

It looks like this is definitely broken :/ Under m-c, m-a, m-b, fp24.0.0.186 appears as "State: Enabled" under about:plugins and about:addons even after pinging the blocklist server several times. Under m-r, the plugin initially appears as "State: Enabled (STATE_VULNERABLE_UPDATE_AVAILABLE)" but when fx pings the blocklist server for the first time, the plugin is re-enabled [1] and is changed back to "State: Enabled".

[1] Blocklist state for Shockwave Flash changed from 4 to 0

I ran through two of the plugins that Remy mentioned in comment#5 and received the same exact results that I received when I tested fp24.0.0.186 (p1494) above:

* fp23.0.0.207 (p1422) - not being blocked, appears as enabled
* fp23.0.0.205 (p1420) - not being blocked, appears as enabled
Flags: needinfo?(kjozwiak)
(In reply to Rémy Hubscher (:natim) from comment #6)
> We have a fix pending for review that you can try here:
> 
> https://firefox.settings.services.mozilla.com/v1/preview/3/%7Bec8030f7-c20a-
> 464f-9b0e-13a3a9e97384%7D/47.0/

Remy, is there a way to test this locally? Or should I wait till it's pushed into the staging server? I took a look at about:config but I couldn't find any prefs that directly point to the blocklist XML file. Do I simply replace the one in the profile folder with the one with the changes from comment#6?
Flags: needinfo?(rhubscher)
(Reporter)

Comment 9

8 months ago
The blocklist has now been updated with the fix. If you have time in an hour or so to confirm, please do, otherwise it can wait until tomorrow.

We still need to update the documentation to include the testing process. If I'm not mistaken, for testing you need to change `services.blocklist.bucket` from `blocklists` to `blocklists-preview`. It shouldn't be needed in this case because I pushed the update live (due to the urgency and minimal diff).
Flags: needinfo?(rhubscher) → needinfo?(kjozwiak)
Jorge, looks like everything is working as expected other than the one issue that I've listed below.

(In reply to Jorge Villalobos [:jorgev] from comment #9)
> We still need to update the documentation to include the testing process. If
> I'm not mistaken, for testing you need to change `services.blocklist.bucket`
> from `blocklists` to `blocklists-preview`.

I'll update https://wiki.mozilla.org/Blocklisting/Testing to include a section on testing changes to the XML file.

Platforms Used:

* macOS 10.12.3 x64 - PASSED
* Win 10 Pro x64 - PASSED

Versions of fp used:

* fp24.0.0.186 (p1494) - being correctly blocked (used m-r and m-c)
* fp23.0.0.207 (p1422) - being correctly blocked (used m-r and m-c)
* fp23.0.0.205 (p1420) - being correctly blocked (used m-r and m-c)

Test Cases:

* ensured that the plugin appears as (STATE_VULNERABLE_UPDATE_AVAILABLE) under about about:plugins
* ensured that the plugin appears as being blocked under about:addons
* ensured that "Update Now" under about:addons is pointing to the correct link
* ensured that pinging the blocklisting server correctly blocks vulnerable plugins
** Blocklist state for Shockwave Flash changed from 0 to 4
** Blocklist state for Shockwave Flash changed from 4 to 4

Issues:

* fp23.0.0.207 (p1422) is pointing to p1494.html rather than p1422.html
Flags: needinfo?(kjozwiak) → needinfo?(jorge)
It seems fixed from the verifier point of view apart from the OS being set to Linux for p1421 while it is not set to Linux in AMO.
(Reporter)

Comment 12

8 months ago
(In reply to Kamil Jozwiak [:kjozwiak] from comment #10)
> * fp23.0.0.207 (p1422) is pointing to p1494.html rather than p1422.html

That's okay because they overlap. 23.0.0.207 is the maximum in 1422 and the minimum in 1494, so both are valid blocks for that version.

(In reply to Rémy Hubscher (:natim) from comment #11)
> It seems fixed from the verifier point of view apart from the OS being set
> to Linux for p1421 while it is not set to Linux in AMO.

It looks like the OS was not set to Linux on the kinto side. I just made that adjustment. Good catch.
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Flags: needinfo?(jorge)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.